Jon
07-11-2005 05:29:36
Me again.
I was nosing around the SceneManager class (trying to answer the question 'how is a renderable written to hardware') when I came across something which might be interesting.
(imagine my embarassment if this code isn't used by PLSM)
OgreSceneManager::renderSingleObject has a member RenderOperation, which appears to be initialized with a op code for processing triangle lists. Now, this is a safe choice for most things, but for terrain I would imagine that a triangle fan would be a more efficient render.
Its sort of a pity that the operation is static (I would expect this to be a good candidate for a member of the renderable). The current code appears to use the same render op for everything rendered.
There must be a reason for this, you say? Perhaps the object is 1G in size? Nope, maybe about 20 bytes + vtable.
Anyhow I came across this while making sure that my chopped up renderable idea could be rendered without breaking anything.
I was nosing around the SceneManager class (trying to answer the question 'how is a renderable written to hardware') when I came across something which might be interesting.
(imagine my embarassment if this code isn't used by PLSM)
OgreSceneManager::renderSingleObject has a member RenderOperation, which appears to be initialized with a op code for processing triangle lists. Now, this is a safe choice for most things, but for terrain I would imagine that a triangle fan would be a more efficient render.
Its sort of a pity that the operation is static (I would expect this to be a good candidate for a member of the renderable). The current code appears to use the same render op for everything rendered.
There must be a reason for this, you say? Perhaps the object is 1G in size? Nope, maybe about 20 bytes + vtable.
Anyhow I came across this while making sure that my chopped up renderable idea could be rendered without breaking anything.
