Jay Stelly wrote:
question would be... Lets say I have two tanks ont he screen.
Does the each tank get it's own instance of the texture
and/or material proxy? What I'm worried about here is one
tank is moving while the other is stationary; but, since they
share the same texture handle both treads appear to be moving.
You probably don't want to do it that way. The OnBind() passes a
pointer to the client renderable. You want to cast that over to your
tank's entity class and ask that instance for the scroll offsets for the
particular tank.
The only way to force different proxies is to use different materials.
It seems like it's simpler to just use the renderable as a key to get to
the data.
Oky, so this solution works if I want to have a different texture for
every tread on the tank. If I want more than one of the same tank on the
screen I'll have to make skins for each instance of a tank. Not the most
practical route I'm guessing, but it would work.
My next question is, how hard is it to up the studio bone limit from 128
to lets say... 512. studio.h has a MAXSTUDIOBONES which seems to define
this value (along with MAXSTUDIOBONESBITS). My reason for asking if
we're looking at animating treads as geometry instead of moving
textures. It would seem the 128 bone limit is getting hit really fast,
since each tread piece requires a bone for animation. I've been playing
with compiling studiomdl with this changed, but it seems to run into a
few other problems after the bone limit is moved up. Anyways, your input
has been very valuable so far. Anything else you can shine light on
would be greatly appreciated. In the mean time I'll continue to work on
getting studiomdl to accept more bones.
James
Jay
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
