3D basics
Blitz3D Forums/Blitz3D Beginners Area/3D basics
| ||
| I've been working on Star Control/Space War clone with 2D graphics for some time now and to enhance the visual appearance I created the ship models with Blender. Now I've started to think that what the hell, why not do it in 3D with those models. It would certainly look better and probably perform better as well. I've coded for a very long time but 3D programming is totally new to me. So there are traps unknown to me that I wish to avoid. 1) I have a world with a lot of objects (hundreds). With 2D graphics, it was sensible not to draw objects outside the view. Does this apply to 3D so that when an object comes close to the view you create the entity and delete it when it gets far enough? Or does B3D perform better when I create all entities at start of game and move those objects every tick? Note that I would be using the 3D only to draw the graphics. Position and orientation of the entities would still be 2D, stored in the x,y,r variables of the object TYPE structure. 2) Is it sensible to have the camera at 0,0 coordinates all the time or have it move with the view? I mean with stationary camera the entities would move as if the view was moving. 3) I noticed that changing the orientation of the objects, degrees are used. Now if for example roll crosses 360 degrees to say 375, and in the program I mod this to 15, will there there be a visible -360 degree turn, especially when tweening is used? |
| ||
| 1) Creating and destroying entities is not generally how you would be culling objects most of the time. In B3D the only objects that get rendered are those which have a visible face within the camera's view and range. The entire geometry of those objects is flung to the card, though, so be wary of that. 2) No it is not sensible. This is what happens anyway but B3D is kind enough to abstract the process out so you can think of the camera in terms of it moving through 3D space. The only time you might consider it is at very large coordinates as mathematical errors can apparently manifest themselves as rendering errors (never experienced it myself - I guess the numbers have to be massive). In other words, keep the worldspace that you use within a sensible range of (0,0,0) but don't feel that you have to keep the camera static. 3) Check. (EDIT: As in "test it and see", not "sure". Cos I have no idea.) |
| ||
| You probably don't want to be using Euler angles for a space game. They're subject to a phenomenon known as gimbal lock ( http://en.wikipedia.org/wiki/Gimbal_lock ) and if you could stand to learn quaternions or matrices you'll avoid this problem. I think 2 might be a good idea. I think it could resolve a lot of niggling problems which might occur later in the project. It's far from essential, of course, but I wouldn't say it was bad idea anyway. |
| ||
| I don't think gimbal lock is a thing to worry about, since I use only x and y positions and roll. Yaw and pitch won't be touched except for possible scripted cinematics or such. About 2) I haven't decided yet on how large the world should be. The 2D version has an infinite world as far as a float can handle, but this isn't good since all interesting things happen at near 0,0 coordinates. I rejected the Star Control solution of flipping ship position to other side of world as too unrealistic, but all other solutions feel unrealistic too. Still I think I'm going to have the boundaries of the world relatively small since this is an action game and there is no need to travel distances. So moving the camera is probably not an issue? |
| ||
| I'd only recommend a fixed camera position for certain types of games. If you were making an R-Type style game (a sideways "scroller") you might choose to use a static camera and move the objects past it. The reason for this is that all objects move in the same direction (with perhaps a few exceptions) but in a space sim where more directions are involved, its probably easier for you to use a dynamic camera. |
| ||
| 1. 3d culling will probably be fine. Note that your own culling may be faster (because you can make assumptions about the maximum size of entities) but profile your game first before wasting development time on what may be a useless and tiny optimization. 2. Whichever is easier for you, which would probably be moving the camera. The farther you get away from (0,0), the less precision is available (the coordinates are floating point,) however, this may not be a problem for you. You can always change it later. 3. I do all my tweening by hand. I've heard there are some problems with the Blitz3d tweening system, but that isn't why I do it myself - I just prefer to have more control over the process (acceleration vs. average velocity.) |
   |