Advertisement

For all 3D isometric programmers

Started by August 01, 2001 10:33 AM
5 comments, last by eis_os 23 years, 6 months ago
Hi I want to say something to all 3D isometric programmers: Every time I see some questions about Isometric as full 3D and new IsoEngines fully 3D but all time I get a little confused. I think full 3D is very good, some good Engines are here, some I can’t get to run . But some question are widely open: What about 2D/3D Mix Engines ? Nothing here really My currently Engine WinRT is like this, with many good side effects and very negatives. (http://allvb.de.vu/winrt) Creating 3D Objects A lot of work, to get these good looking and to get this into the Engine. What about handling the Objects in 3D Engines ? A great terrain with lighting, but no Objects in it ! Hmm, you could say use Z-Buffering, but how to calculate these Z-Values for every tile and how to move big objects from one tile to another. How we could use the mouse ? Our colourful Picture method doesn’t work on height maps. I use some special GDI Tricks in WinRT to get the mouse titles because you haven’t any 3D Coordinates in my 2D/3D Engine(very negative) The Answer Raycasting ? No, what about many Objects close together or selecting titles ? (you can then use slow float math routines, ok, but not so good.) I haven’t seen a non commercial 3D IsoEngine with these feature and I have seen many. What about your opinion ? Hope you have answers. cu
You''re over thinking this whole thing.

Tombstone uses ray casting to calculate the tile the mouse is over. Works great and won''t need to be changed ever even if the engine is switched from billboarding the tiles to full 3D tiles.

There are rules in the world that keep the issues you mentioned from occuring.

3D objects are more difficult initially but once you have one working the rest is easy.

Moving objects in 3D is no different than in 2D. You''re confusing the look with the data that makes it up. Data can be visualized in an infinite number of ways.

Ben

Icarus Independent

Jump Down The Rabbithole
Advertisement
I wrote a fast algorithm a while ago for finding out where in the heightmap the user has clicked. It''s really only half as hard as it looks.

I don''t see the trouble with the 3D objects either, I mean, if you calculate the coords of a bitmap or those of a 3D object, doesn''t it come out the same? Especially, if you use D3D/OGL for the terrain, you can''t suddenly use DDraw for the objects or so, you just use polygons (billboards) again. So instead of having, say, 150 polys, you have two. Is there such a difference there?


I''m currently working on an iso/3D hybrid which is mainly artificially limited to iso, as the vertical position and angle are fixed, and it''s orthogonal projection. (the camera is rotatable round the Y axis though) The rest is basically a 3D world with a heightmap and a load of 3D objects, and some neat lighting. If you use OOP properly, the management of all that is really no problem.


- JQ
Infiltration: Losing Ground
"Crap posts are fertilizer. You have to fill the Lounge with crap in order for anything useful to grow." -runemaster
~phil
Hi

quote:
You''re over thinking this whole thing.


Hmm, but the 3D Engines here are not working with the mouse right.

Then is my question why there aren’t some tips for the other posters here to help ?

JonnyQuest:
I know the Raycasting Routine Source from Infiltration Losing Ground(The VB Version),
but there aren’t very fast if you use many Titles. You use bigger Tiles then I do, thats another perfomance boost.

cu
(!!)
I don''t use any raycasting whatsoever, and it''s completely independent of tile size. The only performance difference is the possible hight of a tile. The larger the range is (I had it at 0-255 pixels) the slower it is. However, with my tiles it took about 2-3 milliseconds or so, and that was with VB, don''t forget. I don''t see your problem, apart from that you probably didn''t read my code properly.
In my new version of the engine (c++) the map is fully rotatable, so I will have to use some other algorithm.

- JQ
Infiltration: Losing Ground
"Crap posts are fertilizer. You have to fill the Lounge with crap in order for anything useful to grow." -runemaster
~phil
quote:
I don''t use any raycasting whatsoever, and it''s completely independent of tile size.


Sorry, you use other vector math, I know :-)
But my Routine is also independent of title size.

Thats shows us ray casting to calculate isn''t the only answer.

cu
Advertisement
As far as picking is concerned you can do a ray-triangle
intersection test.

However you do not want to be testing every triangle in the
world. So here again we have to talk about bounding volumes.

If the ray does not intersect the bounding volume then it
cannot possibly intersect the children (Triangles). You
need to organise your data so it is spatially sorted. You
get other benefits.

If your level has 20k plus triangles in it then it would
be utter madness to throw all these triangles at the
renderer when you might only end up having a few hundred
on the screen. Same with collision detection,same with picking
and so on.

What is your explicit question about the Z buffer? Remember
that although your ground tile is skewed on the screen it''s
local coordinates are probably rectangle. It is only the projection that makes it diamond. It is still a rectangle in real life.

If you need to compute the z coords of your transformed
tile then you have a couple of options.

1. Most 3D packages will render the Z buffer out alongside
your image. (Compositing software needs this)

This Z buffer will be in world coordinates so you have to
simply subtract by prescanning the image and taking the offsets.

2. Render the tile out and scan convert it yourself and store
the Z values.

In both cases add the world_Z offset to the local Z of each
object when rendering. Now you have the Z buffer.

I assume you are talking about 3D billboarded sprites not
mesh based objects when asking that question.



















This topic is closed to new replies.

Advertisement