OoliteProject / oolite

The main Oolite repository.
https://www.oolite.space
554 stars 70 forks source link

VisualEffect requests #27

Open Norbylite opened 11 years ago

Norbylite commented 11 years ago
  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-- commented 11 years ago

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 commented 11 years ago

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-- commented 11 years ago

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 commented 11 years ago

I see more solutions:

  1. 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).
  2. Turn off the shader section of the visual effects created with the forced method (it is enough for me).
  3. Turn off the shader section if contains an invalid uniform only.
  4. 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).
  5. 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 commented 11 years ago

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-- commented 11 years ago

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 commented 11 years ago

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-- commented 11 years ago

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.