Not logged in, Join Here! or Log In Below:  
 
News Articles Search    
 


Submitted by Steven Hugg, posted on February 16, 2001




Image Description, by Steven Hugg



I have been working on a spherical ROAM renderer to render planet-sized objects. When the NEAR spacecraft made its brave plummet today, I began wondering if my renderer could handle a very *non*spherical object -- namely, the dog biscuit-shaped asteroid Eros.

I found an elevation map of the asteroid on this site. Eros is a very irregularly-shaped object -- its most distant point is 14 km from the center and its closest point is only 2 km! Quite an interesting thing to see if a renderer built for spherical objects could handle it.

After a few tweaks, the thing actually worked! What you are looking at is a real-time flyby of the asteroid, about 6000-7000 triangles per frame. I mapped the rock with a generic asteroid texture, and although you can't see it well in these shots the engine generates unique detail textures as you approach the surface. The thing runs about 9-25 FPS on my TNT2 (best when far away, in the first frame) but keep in mind it's written entirely in Java and I haven't finished optimizing :)

This probably isn't the best way to do LOD on an irregular object like this. But it shows that an algorithm designed for a specific purpose (ROAM and flatland) can be perverted into something completely different yet useful!


[prev]
Image of the Day Gallery
www.flipcode.com

[next]

 
Message Center / Reader Comments: ( To Participate in the Discussion, Join the Community )
 
Archive Notice: This thread is old and no longer active. It is here for reference purposes. This thread was created on an older version of the flipcode forums, before the site closed in 2005. Please keep that in mind as you view this thread, as many of the topics and opinions may be outdated.
 
Aetheric

February 16, 2001, 03:01 PM

Very nice detailing during approach. Any chance of a demo for it?

 
David Olsson

February 16, 2001, 03:08 PM

What are your experiences with using java as language for real-time graphics programming? Pros and cons.

I too would like to see a demo.

 
D.P.

February 16, 2001, 03:10 PM

Sure you didn't nick a demo from NASA

 
Leon Rauis

February 16, 2001, 03:14 PM

Now thats interesting.

I've always wanted to see a game that lets the user move through extreme points of detail like that. I've never really seen an engine that you can navigate through space and also land on planets without a loading step or an obvious change in the used geometry.

Applying ROAM to celestial bodies is one of the cooler things I've seen in awhile.

Nice job.

 
morgan

February 16, 2001, 03:31 PM

That is really, really cool. Especially because you're using the real NEAR data.

David: I've been using Java for real time 3D for a while. Using J3D I can render Quake III characters full screen (1024x768), with full animations at about 100 fps. J3D is a good API, but it is a bit annoying. It doesn't work with the Java plug-in (unless you get the user to go through a hairy installation process). The immediate mode is not sufficiently OpenGL like, so you miss many features. I'd really rather just have a very fast drawTriangleStrip than all of the fancy abstraction. No stencil buffers :(... but you do get multitexturing. The retained mode is a little wierd. It has full support for 3D audio and stereo displays (nice), but I don't use these, so it is silly that I have to configure them in the API (not so nice) for a simple 3D app.

Software (write it yourself) rendering in Java can get you about 20fps for reasonable scenes, and will work on any Java platform (don't need J3D).

There are two big performance hits in Java: memory allocation and running under appletviewer. Use 'java' rather than 'appletviewer' for a massive speedup, and use pooled storage to avoid allocation.

See http://graphics3d.com/matrix/3d.htm for more 3D Java hints. I've got a flipCode article on this coming... eventually.
-m

 
Vorteks

February 16, 2001, 03:36 PM

Cool! I've always liked images made from real data. I would be interested in seeing your code, 6000 triangles at 9fps is better then my software engine can do right now, and it's written in native code not Java. Of course your engine is probably hardware-accelerated, but I'm sure you must be doing things more efficiently then I am. Any chance I could take a look?

 
bit64

February 16, 2001, 04:51 PM

I don't think you can do hardware acceleration in Java. Though I am no expert. Why use java at all? I mean besides the novelty of it, why would you ever use java in a graphical app like this?

Having said that, i must say this:
That is very a very impressive screen. I love images drawn from real data. There is just something naughty about it. Vouyeuristic I suppose. Good job though.

 
The Digital Bean

February 16, 2001, 05:47 PM

You can indeed get hardware acceleration in Java. Java3D interfaces to GL or D3D (can't remember which) natively.

Though I am personally not a fan of Java, many have claimed accelerated developments times under Java, which may explain why people use it.

Oh, spiffy pic BTW, I'd love to see a demo.

 
Nathan Hoobler

February 16, 2001, 06:02 PM

I suppose _this_ will show all those who claim LOD will be slaughtered by next-gen T'n'L cards :)

Seriously, though, this is an excellent example of why an LOD approach will always have some advantages over a brute-force method. Simply due to the sheer number of polygons that appear to be used here, a brute-force on current hardware and an equivalent detail level would be impossible. Furthermore, even WITH next-gen video cards, you will still gain an advantage with LOD -- you can ALWAYS use more triangles. If you have a good error metric, a ROAM-esque algorithm will always provide better performance than (and at detail and quality equivalent to) a simple "tri-pusher".

Out of curiousity, is your "dynamic detail texture" a simple noise-based image, or do you have some sort of normal-metric you use? Also, do you use a binary triangle tree implimentation or a quad-tree version? I've personally gotten much better results with the quad-tree, if only because it is very easy to organize the fragments into triangle-fans.

-- Nathan Hoobler

 
Steven Hugg

February 16, 2001, 06:59 PM

Thanks for the kudos. Nathan is right, dynamic LOD is the only way you're going to get
continuous detail from space -> ground level. Until we get giga-poly cards :) More
details: it's basic ROAM, these shots are split-only; I'm working on merge & deferred splitting
now. The texture maps are tiled and generated dynamically using a variety of fractal algorithms
-- this is done in a background thread. Since I'm rendering a full sphere I don't know how
quads would work, but I have had no problems building tristrips.

I started out with the intention of prototyping
in Java and converting to C++ later, but I have not yet had the need to considering how fast
it runs under HotSpot. Developing under Java is just too pleasant to give up for a few more
FPS. I'm using the GL4Java libraries, not Java3D -- I think there's too few
people using Java3D and it can't compete in stability, support, or feature set. Even OpenGL
is suffering feature-wise now that DX8 is out.

There will be a demo at some point, after I work out a few kinks.

Steve

 
DirtyPunk

February 16, 2001, 07:08 PM

LoD should will be around - but ROAM is a nasty algorithm :)

*DirtyPunk stomps on ROAM.

Nice shot though, and good performance for java.

 
Stiefel

February 16, 2001, 07:18 PM

Very nice image, how did you get the asteroid data, did it come in a mesh format already?
I haven't seen a running ROAM demo yet, I wonder how much polygon popping do you see. Or does ROAM include split/collapse "morphing", I can't remember.

Bit64: Using java has indeed some advantages. The most obvious is the
platform independency (even though its not perfect). Another one is that usually development time is shorter due to the "cleaner" java code compared to C++. I saw some studies that claimed a factor of 1.5 to 2. I am not sure if this factor is true, but I am pretty sure that development time will become more and more important in the future. And since the software layer will move more and more away from the actual inner loops (through hardware accleration, texture and lightning) it will become more and more feasible to use java for graphics applications.
You may not see this process in the game industrie yet, but I noticed quite a lot graphics projects in the University/Research area written in Java.
Imagine developing a game that will run instantly on Playstation, Mac, XBox,Pc and the ones you dont even know yet. It might not yet be the time for cutting edge games in Java, but I think we will see java titles in one or two years, since it will be just a consequence of getting the most profit out of a title: A shorter development time plus a bigger market.



 
Squint

February 16, 2001, 08:53 PM

I thought ROAMs strong point was that you don't even GET splits?
popping is probably one of those "... outside the scope of this paper but there are several well informed articles on it if you look ..." things ;)

 
NEGA

February 16, 2001, 10:25 PM

Well, you said that this would be a space sim type thing where more detail would appear as you get closer. Wouldn't it be faster if you were to precalculate a ROAM optimized object ( at a reasonable ammount of detail) then treat it as a progressive mesh. I'm only asking cuz ive been playing around with DX8 and im wondering if that would be faster.

Well anyways looks good. Better than I could do using Java.

 
DirtyPunk

February 16, 2001, 11:51 PM

Dynamic lod isn't the only way. In fact, its not even the best way - partitioned static lod is a far better solution - It will give you much more detail than ROAM for the same cost - Partitioned VIPM is my favourite.

And Partitioned VIPM will get continuous detail from space to ground even though it is pre-calculated.

I just can't stress enough that THE COSTS OF ROAM OUTWAY THE BENEFITS.



 
DirtyPunk

February 16, 2001, 11:53 PM

Better performance by far :)

But if you go to that level - VIPM'd groups of polygons can be done much better with a different error metric than ROAM.

 
luther2k

February 17, 2001, 04:30 AM

Damn, you got there before me! I'm working on a spherical roam algo for planetary bodies too. Nothing new under the sun I suppose.
Anyway, cool stuff and very topical :)

 
Leon Rauis

February 17, 2001, 11:48 AM

ROAM does split triangles recursively, but the way its data structures are set up it allows you to easily propagate changes down to lower detail levels so you get no cracks in the landscape.

 
This thread contains 18 messages.
 
 
Hosting by Solid Eight Studios, maker of PhotoTangler Collage Maker.