Why can’t we just get along??

Weekend is here and I’m going away. Still I spent an hour or two tonight and move code around, which, if you’re into game programming, you know that you will do often. Suddenly you just realize that the code should be somewhere else, in another class, called another thing. Hopefully it will lead to a somewhat cleaner and more logical code. Sometimes it doesn’t :(

There are a some things with PV3D that I really don’t understand why they did like they did. Take size as an example. This is the first time ever (EVER) I stumbled apon a 3dobject that cannot tell me how big it is. It moves around in a 3dspace uses exact coordinates to travel. Still there is no sign of the object knowing what height it has or how wide it is??? There is this bounding box parameter inside the geometry param so it wouldn’t be that hard to implement a recursive check for size both before and after transform. Am I missing something? Why dont I extend the DO3D then and put the functions in there myself? Well, as the whole PV3D is built on DO3D it will not use my extended class so it’s no use.

“So why don’t you just hack the original class then. Just put the features in there?” Well I actually did, and removed it , and did it again and finally removed it  because I know that PV3D is always under development. I am a news freak and always want the latest build and it would be a drag just to update the library manually, putting in my beloved code, each time I update PV3D. Also I wouldn’t be able to write this kind of blog as I cannot expect every single reader out there to hack their basic library classes just to get my examples in here to work.

No, I’m satisfied with just cursing.  :)

So? What’s the deal with layers anyway?? I promised to show you and as I’m leaving in a few minutes, this is an excellent time to bring up that subject.

To be able to draw 3D objects correctly on the screen, the renderer always draws the thing that is furthest away from the camera first. That is logical because if then something appears in the way that is closer to the camera it should overwrite the object far away. But there are times that you actually want to force the renderer to draw the objects in another order thatn it’s default behaviour. This is where layers come in.

In the case of this game, I will use viewportlayers for 2 reasons. 1: the annoying Z-fighting problem and 2: Visual effects.

The Z-problem is a little thingie that has been haunting the 3D world since the beginning of time. As I mentioned earlier the renderer automatically renders the furthest objects first. But how does it know that it is furthest away? Well EVERY single triangle in the 3D-world has got a centerpoint (yes right in the center of the 3 vertices drawing the triangle) and the triangle itself then can calculate how far from that centrepoint it is to the camera. It’s a simple question of distance (and math).

But what happenes if the triangle is a big ass giant triangle? Well it is still the center that decides when it will be drawn. Our arena ground in the game is a perfect example!! It is built up with big ass triangles!! So if our car happens to be on a place on the ground where the centrepoint is behind it. The scene wil be drawn as normal BUT if the car (Defender) moves away at places itself in the ground far away it as a very big chance that the centrepoint is now closer to the camera that the Defendertriangles are. Then the renderer will draw the Defender first and then the ground, causin the defender to suddenly disappear (be drawn uderneath the ground).. hmmm damn.

So now layers is our saviour. We kind of “put” all the objects in different layers and then the renderer will render ALL objects in one layer and then continue to the next layer that has a larger layerindex.  Problem solved!

Effects, we’ll take when we get there. You just think about all cool effects you can do with viewportlayers… mmmm…   in front, in back, in front. Amazing huh? no? Tutorial coming up!