Open Norbylite opened 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
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.
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.
I see more solutions:
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.
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.
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.
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.