Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VisualEffect requests #27

Open
Norbylite opened this issue Jun 16, 2013 · 8 comments
Open

VisualEffect requests #27

Norbylite opened this issue Jun 16, 2013 · 8 comments

Comments

@Norbylite
Copy link
Contributor

  1. The system.addVisualEffect(key, pos); should search the key in shipdata.plists if not found in effectdata.plists (my wip Telescope OXP requires it to show OXP ships).
  2. The VisualEffect.scale should reduce the size of flashers (i.e. Coriolis landing lights) or need a removeFlashers() Method or writable subEntities property to correct the huge flashers when the scale set to small (this is a scenic bug in the current Telescope).
@cim--
Copy link
Member

cim-- commented Jun 17, 2013

  1. This isn't possible to do reliably, because ships and visual effects don't have the same shader uniforms available.

  2. Bug is fixed in 8c8a83e

@Norbylite
Copy link
Contributor Author

  1. It is working, I tried griff_prototype_boa with same contents in plists. The result without shaders still much better than the fallback to a question mark (or to insert all shipdata from all OXP to the effectdata.plist). I need a possibility to force it: maybe set a 3. parameter to true or use addVisualShip(), it can secure to accepted the difference.

@cim--
Copy link
Member

cim-- commented Jun 18, 2013

Working in that it doesn't crash the game, perhaps. But it does generate a bunch of log errors (this with a Griff Adder)
17:45:03.993 [shader.uniform.unpermittedMethod]: Did not bind uniform "engine_power" to property -[OOVisualEffectEntity speedFactor] - unpermitted method. 17:45:03.993 [shader.uniform.unpermittedMethod]: Did not bind uniform "isHostile" to property -[OOVisualEffectEntity hasHostileTarget] - unpermitted method. 17:45:03.994 [shader.uniform.unpermittedMethod]: Did not bind uniform "laser_heat_level" to property -[OOVisualEffectEntity laserHeatLevel] - unpermitted method. 17:45:03.994 [shader.uniform.unpermittedMethod]: Did not bind uniform "uDecalSelect" to property -[OOVisualEffectEntity entityPersonality] - unpermitted method.
So anyone actually trying it would need to be prepared for a lot of bug reports - and this is just for a Griff ship where those particular uniforms falling back to a zero value isn't harmful - imagine you had a ship which used energy / maxEnergy to modulate the intensity of its emission map, so you got a division by zero in the fragment shader.

@Norbylite
Copy link
Contributor Author

I see more solutions:
0. I can document the problem with the manual solution: if the user install a custom ship which produce errors then can copy the ship into the effectdata.plist without shaders (temporary solution).

  1. Turn off the shader section of the visual effects created with the forced method (it is enough for me).
  2. Turn off the shader section if contains an invalid uniform only.
  3. Turn off the specific shader only which refer to an invalid uniform. In this way the Griff Adder can receive at least the griff_normalmap_ships.vertex shader (but need more work to make the checker).
  4. Upgrade the Visuall Effect object to contain the missing properties for the same uniforms with a ship (if the core team permit it, maybe easier and much better than the 3.).

@Norbylite
Copy link
Contributor Author

I suggest a new VisualShip object derived from VisualEffect and amended with the "Bindable ship properties" listed in uniforms wiki page.

If these properties are writable from js then I can fill with proper data, else still avoid the errors and the zero inputs can be handled in the shaders.

@cim--
Copy link
Member

cim-- commented Jun 29, 2013

I'll have a think about this. Option 4 is the only one that guarantees sensible working (models intended for shader-only use need not have anything resembling a sensible diffuse map - have a look at my rings OXP without shaders, for instance) but implementing the additional shader uniforms and making them JS-controllable (probably no need for a separate VisualShip object for this) is a substantial piece of work and a potential maintenance headache to keep them in sync.

@Norbylite
Copy link
Contributor Author

An idea to avoid the "maintenance headache to keep them in sync": if the system.addShips() get a new 'non-solid' parameter and ships created in this way handled as a VisualEffect (can not collide nor get hit nor targeted) and isVisualEffect returns true then the result seems to be usable.

@cim--
Copy link
Member

cim-- commented Jun 29, 2013

We thought about that approach for doing Visual Effects in the first place :) It ends up being even worse that way round because so much of ship behaviour is undesirable (weapons, AI, comms, energy levels, hyperspacing, collisions, etc. etc.) Adding some more dummy shader uniforms would definitely be the easier way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants