Agreed, for static shaders the difference between using a script and XML is very small in terms of flexibility. For animated shaders the script would be much more flexible.
You wouldn't have a whole lot of animated shaders, so the number of scripts called per frame would be a lot less. Also the animation scripts would only be executed once per frame, not for each mesh. If the animation scripts get too heavy it would also be possible to turn them off, or spread out the calls over several frames, without having to change the rest of the rendering pipeline.
There is no problem calling hundreds of scripts per frame, but there is a problem if you start calling thousands.
Fastest function execution
Author
Ah, see now that you put it that way, I still might use the scripts. I realize that I should have been clearer- I think I was very misunderstood! I would not be calling a script per-mesh, it would only once per-shader, and only fixed function pipeline shaders. The script would simply set up the OpenGL states required to achieve an effect. So, the render process goes like this-
1) Go through all objects, sorting, updating, whatever you do to them. Whenever leaving the object, add it to the render queue.
2) Sort the render queue according to some priorities. Shader is first priority.
3) Start the render queue. Get the first object, setup the shader (would be script), and render it.
4) Go to the next object in queue. Repeat step 3, except if the shader is the same do not set it up.
5) Repeat number 4 until you've finished rendering all objects in queue.
So you see, there would probably only be 15 or 20 scripts executed each frame, as there will probably only be that many fixed function shaders. All of the advanced shaders will be GLSL, including dynamic shaders.
So, that is an appropriate way to use scripts, correct? I definitely want to go ahead and try it out. I'll profile it and get back to you.
edit: I forgot mentioning the per-object parameters. In the script, I would have an object that represent the current mesh, so if you wanted to set the color you would say glColor3f(o->color.r, o->color.g, o->color.b); etc. But, this would not be executed per-mesh, it would be compiled and understood by the engine that would actually run c++ code when rendering each mesh.
edit #2: crap, I just realized that what I'm asking doesn't make any sense. I might as well pre-compile everything into c++ code and not worry about running scripts every frame. What I will do is run the scripts once which will setup the states for an object, and interpret that and execute with c++ each frame. Bah, I don't know if that made sense.
1) Go through all objects, sorting, updating, whatever you do to them. Whenever leaving the object, add it to the render queue.
2) Sort the render queue according to some priorities. Shader is first priority.
3) Start the render queue. Get the first object, setup the shader (would be script), and render it.
4) Go to the next object in queue. Repeat step 3, except if the shader is the same do not set it up.
5) Repeat number 4 until you've finished rendering all objects in queue.
So you see, there would probably only be 15 or 20 scripts executed each frame, as there will probably only be that many fixed function shaders. All of the advanced shaders will be GLSL, including dynamic shaders.
So, that is an appropriate way to use scripts, correct? I definitely want to go ahead and try it out. I'll profile it and get back to you.
edit: I forgot mentioning the per-object parameters. In the script, I would have an object that represent the current mesh, so if you wanted to set the color you would say glColor3f(o->color.r, o->color.g, o->color.b); etc. But, this would not be executed per-mesh, it would be compiled and understood by the engine that would actually run c++ code when rendering each mesh.
edit #2: crap, I just realized that what I'm asking doesn't make any sense. I might as well pre-compile everything into c++ code and not worry about running scripts every frame. What I will do is run the scripts once which will setup the states for an object, and interpret that and execute with c++ each frame. Bah, I don't know if that made sense.
What you said with calling the script to set up the OpenGL state could work, though what you said after edit#2 is probably much better.
In my experience it is best to separate the layers as much as possible. The scripting layer should preferably not run during rendering, at most as a step just before rendering each frame. The design will be much cleaner that way, and will be much easier to maintain.
You say that you will only use the scripts for the fixed function shaders. I would suggest you also let the scripts choose what GLSL shader to run, and if the GLSL shader is also an external file the script writer will have complete control.
This would actually be a perfect sample/tutorial to show how to use AngelScript. I will try to find the time to write a simple sample that will show a rotating cube where each side uses a shader controlled by scripts like we mentioned.
In either case I look forward to seeing the result of your experiments.
Regards,
Andreas
In my experience it is best to separate the layers as much as possible. The scripting layer should preferably not run during rendering, at most as a step just before rendering each frame. The design will be much cleaner that way, and will be much easier to maintain.
You say that you will only use the scripts for the fixed function shaders. I would suggest you also let the scripts choose what GLSL shader to run, and if the GLSL shader is also an external file the script writer will have complete control.
This would actually be a perfect sample/tutorial to show how to use AngelScript. I will try to find the time to write a simple sample that will show a rotating cube where each side uses a shader controlled by scripts like we mentioned.
In either case I look forward to seeing the result of your experiments.
Regards,
Andreas
Author
Great, I'd love to see a sample to see a good design of script and app interaction. Thanks!
I'm not sure what you meant by letting the script choose which GLSL shader to run though. Are you talking about hardware support issues, or simply attaching shaders to objects? So there would be a script that specifies which shader goes with which object?
I already have a fallback system that links shaders with higher level "effects." You actually assign an effect to an object and the system decides the best shader to use on current hardware. You mean to let a script decide which effect to use?
I'm not sure what you meant by letting the script choose which GLSL shader to run though. Are you talking about hardware support issues, or simply attaching shaders to objects? So there would be a script that specifies which shader goes with which object?
I already have a fallback system that links shaders with higher level "effects." You actually assign an effect to an object and the system decides the best shader to use on current hardware. You mean to let a script decide which effect to use?
Yes, I meant to let the script choose which effect to apply to the object.
The script could also be allowed choose a different effect in case the GLSL isn't supported on the hardware. That would allow the script writer to choose the fallback method. Wether this is what you want or not, I don't know. Basically I'm just throwing ideas at you :)
The script could also be allowed choose a different effect in case the GLSL isn't supported on the hardware. That would allow the script writer to choose the fallback method. Wether this is what you want or not, I don't know. Basically I'm just throwing ideas at you :)
Hi
What you are looking for is run-time intrinsics code or run-time generated code, angelscript is very fast with this, about 2 or 3 times slower than c++
The compilation of the script to assembler code is made at the program start or at a later time if you want (or recompile if the script chaged), and can use the host machine specific capabilities, 3d hardware where aplicable or software, ss2, 3dnow+, and so
So you end executing machine code, instead of bytecode/interpredtedcode
regards
Lioric
What you are looking for is run-time intrinsics code or run-time generated code, angelscript is very fast with this, about 2 or 3 times slower than c++
The compilation of the script to assembler code is made at the program start or at a later time if you want (or recompile if the script chaged), and can use the host machine specific capabilities, 3d hardware where aplicable or software, ss2, 3dnow+, and so
So you end executing machine code, instead of bytecode/interpredtedcode
regards
Lioric
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
