Sorry your browser is not supported!

Ok, got a new problem. This may be a little difficult to explain, but here goes: Right now I've figured out how to do an "Infinite Space" thing that im using for a tactical space simulator. It's really neat cuz planets appear life-size and days of light speed away. How it works is by simply positioning the planets near the camera in actuality and using a division algorithm to make them move less when near the camera. It works fine so no real problems there. The problem comes when, ofcourse, an object is somewhat far away and you are close to a planet. Now, that planet is still supposed to look WAAAAAAAAY far away, but since it really isn't, it occludes the object (which happens to be a nifty orange spacfighters.... PICS SOON!). No problem, disable z-write on the planet right? Well, yes and no. Depending on the creation of the objects, sometimes the fighter will still be occluded.

How the problem works:
What is happening is that polygons are written in a certain order. Even with no Z-Write, if an object is rendered AFTER another object, it will still occlude it. If it is rendered BEFORE, I get the effect that I am looking for. The problem is that it appears that DBP renders through the objects BACKWARDS from creation. That meens that if I create a space fighter after I create the planet, the planet will occlude it when it shouldn't. I need to be able to dynamically create spacefighters in the game as it is meant to be a tactical game and I would rather not delete ALL planets and other gargantua objects and reload them after I create 1 lousy space fighter. Anyone have any ideas as to how I can get around this???? I may end up stuck doing some really cheap and framerate destroying tricks that I wish to avoid. One thing that would be nice is if I could simply have DB render polygons in the other direction. That would solve my problem right there!

Any ideas folks?

Well, if your planets are in front of your fighters, you don't have a simulation as much as a (broken) hack. The 'fix' is to use a variable scale for distance and separate size scale for models.

Have you ever played table top space games? The white metal figures are cool, but the real ship is usually just a dot on the map. Try tracking each unit's location and size in real world values (say a user defined type). When you position them in world coordinates, establish a sliding scale. Perhaps one unit is 1,000 km, but as you move away from objects the distance scale might change to 10,000 km per unit. Everything stays positioned relative to each other. The second part is to scale the objects so that they are visible, but not grossly overlapping each other. This isn't the real object as much as a hologram representation of the object. [Maybe even deliberately ghosted when not in combat range.]

It's a balancing act, but the end result is a better simulation of your tactical space than objects with variable scales that look right but are positioned wrong.
--
Just my two newtons, TAZ.


A 'table top' example where the distance scale is determined by the hex grid, but the models are scaled for visual appeal and not actual size. Of course, a real time tactical combat game would have a different sense of scale for what is right. One of those being that planets would be huge objects in the background.

http://www.geocities.com/tzircher/tcom_gallery.htm

Dynamic object creation is sadly a bit beyond DBPro's scope - it's not really cut out to handle it's engine that way.

I'd suggest that you store all your ship textures, and load all your ship objects as meshes. Then I'd decide how many ships I wanted as an absolute maximimum, like 100 ships - I'd create 100 of the most common ship and store the ship type in an array, and also hide it. When you want to change a ship type, you use the CHANGE MESH command and change the texture - which is much faster than loading the object again, and more importantly you retain control over ZDepth orders. Theres also are a few little tricks you can pull with this technique to maximise your frame rate - like using lower res textures if the object is very far away.


Van-B

I don't own DBPro yet. Can you specify your models as separate groups? So that you can tell DBP to render one set and then switch out the current group and tell it to render another?

Also way back when I was working on 3D stuff in the late 80's, you used the near and far clipping planes to adjust Z-buffer resolution. So you would set up clipping planes, render far stuff. The clear the z buffer, change the clipping planes, and render near stuff. Is this doable in DBPro?

Yeah, SET CAMERA RANGE will set the start and end range of the camera.


Van-B

Ohh, and if you disabled the backdrop, then set the camera range to 1000 to 10000, it would render the far away stuff, then setting it to 5 to 1000 it would then render the near stuff. It would probably take 2 sync's to do it, but I reckon it's doable.


Van-B

@VanB

I'm assuming you wouldn't be able to tell it to clip from, say 50000, to 1000000 now could you? Maybe farther.... anyways my system can handle such numbers easily. But that's not really my problem. My problem is I have a system but it has a few bugs. Actually, you may have solved my problem, but I'm afraid of the memory it will require. Simply loading all my objects and then loading the planets will do, but if I have 100 objects and only 20 on the screen, it does seem like a bit of a waste of memory... oh well, I'll try to stick with lower poly counts and see what happens. Changing meshes is a great idea, though.

@Zircher

Sounds great. I've tried something similar in the past but couldn't quite get the algorithm working right. If my next move with the engine fails miserably, though, I may try it again. It's been a while since I tried it last and I like to think I got smarter down the programming road, so maybe if I end up trying it again, I can get it to work right!

@All

For the most part, I think VanB and FLY135 kinda missed the point a bit, but I do admitt my explanation was difficult to understand. I thank everyone for their help!