-
Notifications
You must be signed in to change notification settings - Fork 70
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
Comments
|
|
Working in that it doesn't crash the game, perhaps. But it does generate a bunch of log errors (this with a Griff Adder) |
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. |
The text was updated successfully, but these errors were encountered: