Naughty:
That is correct. I did that for speed reasons.
It probably wouldn't be too hard for one to modify the system to support it again though.
Basically the reason for the requirement as far as I can remember, is that accessing the vertcies with the regular Blitz functions was slow, and storing it in banks was faster. Or maybe I did that as a result of needing to in order to implement a much faster octree-based polygon culling system which I never got around to doing, which wuod have required objects to remain unrotated/scaled, and would have required the data to be stored in a special way in banks.
For whatever reason I did it, the vertex data of the receivers is stored in banks. You would need to exchange each bank access with the appropriate vertex access command.
But I just remembered another couple issues.
First, in using the banks, I did not need to loop through an object's various surfaces when rendering the shadows. So you'd have to have a surface loop in addition to the vertex loop in the main rendering loop of the shadow system.
Second, once you have taken these vertex values from the object's mesh that won't do you any good alone because they'd be untransformed... They wouldn't be scaled or rotated...
Hm... Actually come to think of it, that changes things. Scratch all that.
There is no reason to change the code that relies on the banks, because the vertex data returned is always going to be the same anyway. The only thing that needs to be done, which would result in a slowdown, would be transforming the vertex data according to how the receiver is transformed. There is also a bounding sphere calcualted for the receiver, and that radius value would have to be scaled according to the current scale of the receiver. It would be a little more complicated to allow the receiver to be scaled differently on each axis, but only if you cared if the bounding radius was optimal, rather than being a bit larger than it needed to be.
But the transformations of the vertex data would be handled with the tform commands built into Blitz, so that wouldn't be too hard to implement.
So that's why it is the way it is. Because I'd planned to have a better culling system, and that would have required static receivers, and transforming the points from receiver space to global space comes at a speed penalty. And if the receiver has a LOT of points, then that comes at a really big speed penalty. You'd definitely have to split your receivers into small objects so they could be culled. Right now you can sort of get away with not doing that.
Of course I could probalby solve that speed issue by transforming the light plane into receiver space per receiver instead of the receiver into global space, but that'd probably be a huge pain to do.
That is correct. I did that for speed reasons.
It probably wouldn't be too hard for one to modify the system to support it again though.
Basically the reason for the requirement as far as I can remember, is that accessing the vertcies with the regular Blitz functions was slow, and storing it in banks was faster. Or maybe I did that as a result of needing to in order to implement a much faster octree-based polygon culling system which I never got around to doing, which wuod have required objects to remain unrotated/scaled, and would have required the data to be stored in a special way in banks.
For whatever reason I did it, the vertex data of the receivers is stored in banks. You would need to exchange each bank access with the appropriate vertex access command.
But I just remembered another couple issues.
First, in using the banks, I did not need to loop through an object's various surfaces when rendering the shadows. So you'd have to have a surface loop in addition to the vertex loop in the main rendering loop of the shadow system.
Second, once you have taken these vertex values from the object's mesh that won't do you any good alone because they'd be untransformed... They wouldn't be scaled or rotated...
Hm... Actually come to think of it, that changes things. Scratch all that.
There is no reason to change the code that relies on the banks, because the vertex data returned is always going to be the same anyway. The only thing that needs to be done, which would result in a slowdown, would be transforming the vertex data according to how the receiver is transformed. There is also a bounding sphere calcualted for the receiver, and that radius value would have to be scaled according to the current scale of the receiver. It would be a little more complicated to allow the receiver to be scaled differently on each axis, but only if you cared if the bounding radius was optimal, rather than being a bit larger than it needed to be.
But the transformations of the vertex data would be handled with the tform commands built into Blitz, so that wouldn't be too hard to implement.
So that's why it is the way it is. Because I'd planned to have a better culling system, and that would have required static receivers, and transforming the points from receiver space to global space comes at a speed penalty. And if the receiver has a LOT of points, then that comes at a really big speed penalty. You'd definitely have to split your receivers into small objects so they could be culled. Right now you can sort of get away with not doing that.
Of course I could probalby solve that speed issue by transforming the light plane into receiver space per receiver instead of the receiver into global space, but that'd probably be a huge pain to do.