Ticket #976 (new idea)
programmable rendering models
| Reported by: | ArcRiley | Owned by: | |
|---|---|---|---|
| Priority: | Medium | Milestone: | beta4 |
| Component: | soy.models | Version: | Trunk |
| Keywords: | Cc: |
Description (last modified by ArcRiley) (diff)
Classes in the soy.models namespace (inheriting soy.models.Model) provide all of the rendering in a scene. There are many classes available but, since rendering takes place in a background "no GIL" thread in entirely compiled code, new classes that provide rendering cannot be written in Python.
We've had this idea floating around for awhile, that it could be possible to inherit Model and "program" the rendering code using a subset of GL syntax.
This would look and act like a Python method soy.models.Model.render. It's run when the method is added but instead of actually performing the OpenGL operations it compiles them to a serialized command array. Tokens on the array represent OpenGL calls and their arguments, some values representing variables of the model or body it's rendering at (ie, position).
On render, the serialized command array is "run" from C, which would likely look like a large switch statement with most cases forwarding the array pointer as arguments to that statement are read and the actual OpenGL call run.
To Python, it would act and feel as if Python code was being run, even overridding the rendering method in realtime could have the desired effect.
The rendering properties of Mesh/etc could likewise be accessed and run this way - in fact there may be an argument that the custom C rendering code of all these classes should be abstracted to this serialized command array and the C-side classes only differing by the datasets they contain (ie, Model class has no concept of verticies or faces, that's added by Mesh).
This can eventually include Python programmable shader models, where GLSL code can be entered from Python and happily compiled and run in the nogil rendering thread.



