I have another project that already works to create DirectX shaders, and I wonder if it would
be cool to adapt it to generate Control classes for nodes in the JMonkeyEngine scenegraph.
Features of the current application are:
template based: the node structure can be exported to any language
node system : nodes are defined in a platform independent way.
buffers: output can be written to different buffers, buffers can be written in a user defined order to different streams (files)
Math node: I’m very proud of this one. I created a math node that makes it possible to visually create a math formula. This solves the problem that node based systems
can become very spaghetti like.
blocks : functionality can be converted to a block that can be shared with other developers.
What I would need to do to make it work for JMonkeyEngine:
Create extra nodes that support JME paradigms
Adapt the templates to generate subclasses of the Control class.
The structure is geared towards shader stages, and should be changed to allow methods within the Control class.
Would it be worth the trouble to make these changes? Would there be any intrest for it?
I think the Fomular is superb but “kind of overkill” for shader programming. The rest is superb, kudos if you can make it a plugin for SDK, in corporation with the current ShaderNode editor
I think the Fomular is superb but “kind of overkill” for shader programming. The rest is superb, kudos if you can make it a plugin for SDK, in corporation with the current ShaderNode editor
Ok , I will take a look at the ShaderNode editor first, maybe there is more use there for my editor. Maybe also a small demo of using the system for a Control java class.
With regards to the formula editor, the representation of some specular models can take a lot of screenspace in a noded based system
Math node: I’m very proud of this one. I created a math node that makes it possible to visually create a math formula. This solves the problem that node based systems.
I’ve also want to write a General Node based system my self. Composing over hand-writing is a fascinated idea. But… It should be user-friendly and also should targeted to something specific. For short, if it’s so general…it will not really useful.
Regarding some container concept ( such asFormula)
Other node base system introduce “container” to group similar nodes into one, which hide unnecessary nodes which take too much space. Those container is not actually a “Node”, because it’s just for presentation ( not really visualization the value of the calculation inside a node).
As if you make more and more then too much Math Node, it will become more like a “syntax system” and lose some reusable, lose some flexibility and lose some visualization ability also in the progress. So eventually a node visualization should be expressive, can be come inexpressive as intended!
I suggest to use only “common” Math nodes. And if possible, giving the MathNode an icon: a graph, a common usage… Ex: The Specular_highlight http://en.wikipedia.org/wiki/Specular_highlight
Phong:
or
Gaussian:
@atomix said:
* Math node: I’m very proud of this one. I created a math node that makes it possible to visually create a math formula. This solves the problem that node based systems.
I’ve also want to write a General Node based system my self. Composing over hand-writing is a fascinated idea. But… It should be user-friendly and also should targeted to something specific. For short, if it’s so general…it will not really useful.
Regarding some container concept ( such asFormula)
Other node base system introduce “container” to group similar nodes into one, which hide unnecessary nodes which take too much space. Those container is not actually a “Node”, because it’s just for presentation ( not really visualization the value of the calculation inside a node).
As if you make more and more then too much Math Node, it will become more like a “syntax system” and lose some reusable, lose some flexibility and lose some visualization ability also in the progress. So eventually a node visualization should be expressive, can be come inexpressive as intended!
I suggest to use only “common” Math nodes. And if possible, giving the MathNode an icon: a graph, a common usage… Ex: The Specular_highlight
My 2 cents as always
Those are very valid points. I think usability testing will definitely be in order, maybe the solution is to create different profiles (simple shader, post effect shader, experimental shader, …)
The same type of node-editor such as this and the jME shader nodes could maybe be used to compose controllers on spatials. Would be sort of cool to add a “follow spatial” controller and wire it to an “Orbit camera”-controller and attach to a spatial.
Nice work. I’d also say that it probably makes most sense to extend the existing ShaderNode editor with some of this functionality, else there would be a lot of doubling in features, plus these editors always follow their own logic and with ShaderNodes we already implemented such a thing in the engine and SDK.
As for the idea of @jmaasing, it sounds promising but in the end the applications of Controls are just too varied to make a static editor from them, just by defining input and output types you already restrict the functionality. For shaders its pretty obvious what kind of data etc. they can pass to other nodes, for Controls not so much. For that it probably makes more sense to have specialized editors, say one for transforming Controls (animation, paths etc.) and another one for steering behavior etc. But then again not all games use Controls for the actual gaming logic, only to apply it to the Spatials in the end (e.g. grab location and animation data from an ES and apply it to the models).
@normen said:
Nice work. I'd also say that it probably makes most sense to extend the existing ShaderNode editor with some of this functionality, else there would be a lot of doubling in features, plus these editors always follow their own logic and with ShaderNodes we already implemented such a thing in the engine and SDK.
Ok, think the best thing I can do is to first study the ShaderNode editor, to see if/where I can make a contribution. I think the math editor is something that maybe could help with the creation of the shadernode blocks themselves.
For the second part, I’ll probably do some experiments. It’s indeed not easy to make a node based language turing complete. Maybe a little bit of functional programming concepts could solve that. Anyway, I have a course in the second semester where I use JMonkeyEngine to teach game engine concepts, and I could try out some ideas there.
One “problem” with the current shader nodes system is that we cannot generate shader code dynamically… it has to be specified in shader node file. But there might be some workaround for that.
