Saturday, September 25, 2010
at
3:52 AM
|
2
comments - [Click to post comment]
Wow, this blog post is long overdue. The past few months had been a rather busy month for me. I had to juggle between a few projects which saw work on aftershock slowed down to a crawl.
However, I'm now back to speed. :-D
So today I'm going to talk about our effects system. The effects system has been in my head for a long time. I had been doing lots of thinking through making sure that my idea was sane and useful. I'm rather proud to say that the effects system is very well capable of complex effects that combines lighting, particles, ribbon trails and even animations.
The idea was not a revolutionary one though. What I came up with was a node graph system to define a behavior of a given effect. Imagine blender's material node system but instead of applying on materials, we apply on entities. If you're quick to notice, this idea is pretty much a high level primitive scripting system. Only that instead of using scripting, we build nodes. One could also think of it as shader nodes for effects.
However, to keep things simple, I omitted conditional nodes and forced all value type to be float. Hence we only have float, float2, float3 and float4 value type.
Bellow is an example of how a flickering light effect can be described with the node system:
Figure 1 - Flicker Light Effect Example
To aid the ease of node building, I've also made the node system do auto conversion between the defined types. This mainly means single float can be easily converted automatically to multi float type. Any other combination is not possible as that would be ambiguous as shown bellow:
Figure 2 - Value Type Auto Conversion
Adding on top of that, I've allowed nodes to support multiple slot mode. This is similar to the method overloading of C/C++. The only difference is that the number of input/output slot must retain the same. Only the value type can be different. With this, depending on how the node graph is linked, my node compiler will use the best fit mode for any node processing.
Bellow is an example of how it would work given a mock up node graph scenario:
Figure 3 - Multi Slot Mode Use Case Example
So why do we need this? This is very useful for primitive operations for example Addition, Subtraction and Multiplication nodes which requires different input and output value types for all possible combination.
Once the effect node graph is defined, we can simply bind them to entities that demands the given effect. :-) Obviously the whole implementation and design is much more complex compared to this. However I felt the node graph idea to be most interesting to report about. Imagine the possibilities of extending this into animation systems which interestingly is very similar to the animation blend tree idea.
Oh yeah, one nice effect of the node system is that when designed carefully, we can reuse the compiled node graph on all instance of the same effect in the scene. Also, if written properly, this is actually much more optimal compared to using a scripting engine which I personally feel should be left to handle less CPU intensive logic like game rules.
There, I hope this is long enough to justify for my lack of blog post. I will put up some programmer art effects video if possible when I get the effects system running and tested. As of now, I already have the node graph system and entity binding in place. However, I've yet to deal with all the possible node types I planned to add to allow complex effects. Still, having the base system means we're pretty close to a complete effects system already. So stay tuned. ;-)
However, I'm now back to speed. :-D
So today I'm going to talk about our effects system. The effects system has been in my head for a long time. I had been doing lots of thinking through making sure that my idea was sane and useful. I'm rather proud to say that the effects system is very well capable of complex effects that combines lighting, particles, ribbon trails and even animations.
The idea was not a revolutionary one though. What I came up with was a node graph system to define a behavior of a given effect. Imagine blender's material node system but instead of applying on materials, we apply on entities. If you're quick to notice, this idea is pretty much a high level primitive scripting system. Only that instead of using scripting, we build nodes. One could also think of it as shader nodes for effects.
However, to keep things simple, I omitted conditional nodes and forced all value type to be float. Hence we only have float, float2, float3 and float4 value type.
Bellow is an example of how a flickering light effect can be described with the node system:
Figure 1 - Flicker Light Effect Example
To aid the ease of node building, I've also made the node system do auto conversion between the defined types. This mainly means single float can be easily converted automatically to multi float type. Any other combination is not possible as that would be ambiguous as shown bellow:
Figure 2 - Value Type Auto Conversion
Adding on top of that, I've allowed nodes to support multiple slot mode. This is similar to the method overloading of C/C++. The only difference is that the number of input/output slot must retain the same. Only the value type can be different. With this, depending on how the node graph is linked, my node compiler will use the best fit mode for any node processing.
Bellow is an example of how it would work given a mock up node graph scenario:
Figure 3 - Multi Slot Mode Use Case Example
So why do we need this? This is very useful for primitive operations for example Addition, Subtraction and Multiplication nodes which requires different input and output value types for all possible combination.
Once the effect node graph is defined, we can simply bind them to entities that demands the given effect. :-) Obviously the whole implementation and design is much more complex compared to this. However I felt the node graph idea to be most interesting to report about. Imagine the possibilities of extending this into animation systems which interestingly is very similar to the animation blend tree idea.
Oh yeah, one nice effect of the node system is that when designed carefully, we can reuse the compiled node graph on all instance of the same effect in the scene. Also, if written properly, this is actually much more optimal compared to using a scripting engine which I personally feel should be left to handle less CPU intensive logic like game rules.
There, I hope this is long enough to justify for my lack of blog post. I will put up some programmer art effects video if possible when I get the effects system running and tested. As of now, I already have the node graph system and entity binding in place. However, I've yet to deal with all the possible node types I planned to add to allow complex effects. Still, having the base system means we're pretty close to a complete effects system already. So stay tuned. ;-)
Posted by
Lf3T-Hn4D
Posts
