TSMesh::smObject Alternative?
by Tim Dix (Raverix) · in Torque 3D Professional · 05/06/2009 (8:34 pm) · 7 replies
Several static variables inside of TSMesh have been removed, the one I'm looking for specifically is the SceneObject* TSMesh::smObject, is there an alternative way to find get the scene object now?
About the author
Recent Threads
#2
Trying to adjust the way shaders work on a per object basis. IE: One player has X shader value on, the other has Y shader value, etc and so forth.
Edit:
I'm thinking I can just add a reference to the scene object to the TSRenderState class and then I'll have access to it throughout, unless you know a cleaner way?
05/06/2009 (8:45 pm)
Thanks for the quick response.Trying to adjust the way shaders work on a per object basis. IE: One player has X shader value on, the other has Y shader value, etc and so forth.
Edit:
I'm thinking I can just add a reference to the scene object to the TSRenderState class and then I'll have access to it throughout, unless you know a cleaner way?
#3
If you can give me more details as to what sort of shader work your doing maybe i can think of a better way.
05/06/2009 (10:41 pm)
Thats probably as clean as it will get from what i know.If you can give me more details as to what sort of shader work your doing maybe i can think of a better way.
#4
What I want to do is be able to adjust standard properties of the material on a per-object basis, such as the scrolling / wave animations.
05/07/2009 (3:21 am)
Well, I was following a forum post, however, I don't like the way it was implemented there.What I want to do is be able to adjust standard properties of the material on a per-object basis, such as the scrolling / wave animations.
#5
The batching in the bins is often done by looking for the Material* to change... different material... different batch. So if your changing the material settings between objects that would break that batching and you'll get the wrong materials on objects.
Still... it can be done. Passing the SimObject thru the TSRenderState is really the best bet from what i can see.
05/07/2009 (12:24 pm)
That will be a tricky task.The batching in the bins is often done by looking for the Material* to change... different material... different batch. So if your changing the material settings between objects that would break that batching and you'll get the wrong materials on objects.
Still... it can be done. Passing the SimObject thru the TSRenderState is really the best bet from what i can see.
#6
I found this snippet elsewhere on the forums, but not sure what valid values for paramName would be. Anyone familar with this function? I see it takes things in the form of ("$variable") but I'm not sure which variables it understands.
05/07/2009 (12:40 pm)
Well, I was thinking maybe better way than passing the SceneObject all the way through would be to pass an overriding Material, or maybe just some of the properties I want to override, down the pipe.MaterialParameters* matParams = mMatInst->getMaterialParameters();
MaterialParameterHandle* handle = mMatInst->getMaterialParameterHandle(paramName);
if (handle)
{
matParams->set(handle, paramValue);
}I found this snippet elsewhere on the forums, but not sure what valid values for paramName would be. Anyone familar with this function? I see it takes things in the form of ("$variable") but I'm not sure which variables it understands.
#7
IMO and overiding material is a better solution if it works for your models... like what if you have two different materials on your DTS. I think at one point we had one in TSRenderState, but i don't see it now.
05/07/2009 (1:46 pm)
Those are used for setting shader constants on the material, but it won't help you unless your the last one to set the constant. Typically the final constants are set within the matinst->setupPass() call.IMO and overiding material is a better solution if it works for your models... like what if you have two different materials on your DTS. I think at one point we had one in TSRenderState, but i don't see it now.
Associate Tom Spilman
Sickhead Games
If you look we now pass TSRenderState thru the TSShapeInstance render calls. That holds on to a bunch of settings the shape needs for submitting its render instances.
What specifically are you trying to do?