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

Submitted by Ville Miettinen, posted on September 19, 2000

Image Description, by Ville Miettinen

Here's a screenshot from one of the new SurRender Umbra demos. Umbra is a commercial visibility determination library that can be plugged into any 3D rendering engine to handle early culling of hidden objects (hierarchical VF culling, occlusion culling, portal culling, contribution culling). The library supports completely dynamic scenes and requires no visibility pre-processing.

This real-time demonstration shows how objects can be "on-demand loaded" from massive world databases. The demo loads objects from a database file when they become "almost visible". The loading never stalls the rendering - if an object hasn't been loaded in time, it is not rendered until its data has been fully streamed in. Objects that have not been visible for a while are removed from the database and swapped back to the disk.

The database in the picture contains two million objects. All models have 108 triangles and 258 vertices, thus pumping the total triangle count to 216M. The database file requires 130Mb of disk space. The memory used by the visible portion of the database (and other Umbra allocations) is around 1.5Mb. The database is not static: 120,000 of the objects are moving around every frame. The startup time of the application is a couple of seconds.

The image on the right side of the window shows a bird's eye view of the situation. The view frustum has been marked in transparent gray and the objects visible to the camera on the left are shown.

This and other Umbra demos can be downloaded from the SurRender Umbra home page ( All of the demos run through Umbra Visualizer, a fully portable (OpenGL+GLUT) rendering framework.


Image of the Day Gallery


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.

September 19, 2000, 06:15 AM

Wow, I sure hope you have one huuuuuuge monitor for text THAT small.


September 19, 2000, 06:55 AM

The demo is impressive!
Is there any 'practical' demo with combined outdoor and indoor scenes?
For example some city simulation would be cool, though I bet it would take some effort from 3d modeller d:

Cheers, Altair

John van der Burg

September 19, 2000, 11:07 AM

Very neat stuff! :)
I tested the demo, and it's great.
Will probably also implement Umbra into Oxygen3D, instead
of re-inventing the wheel :)

p.s. The Umbra documentation mentions somewhere that you can also feed low-detail models into Umbra, instead of using the full detail model. But when using an algorithm like progressive meshes, it can happen that there will be an edge collapsed which will result in incorrect occlusion.
Imagine a square with a round hole in it. Now a low detail version might have a non-round hole in it anymore, because some specific edges have been colapsed. I hope you still understand what I mean, I'm don't know so good how to explain in English without a drawing :)
But how does Umbra handle this? I guess it doesn't handle these cases, and that you should watch out for this yourself?

- John


September 19, 2000, 04:21 PM

What a great peice of work!

Out of curiosity, are you using standard threads in C++, or your own time slicing code to handle streaming in the new objects without disturbing the rendering? Or is it the hardware card enabling you to carry on with your own processes, while the rendering remains a constant process? I would be interested to know this.


September 19, 2000, 11:42 PM

Impressive... but as visibility is computed for every frame (I assume), how does this stack up against precalculated visibility models? I don't expect it to be as fast, but some indication of speed would be nice (percentage of time spend in the visibility code).

And I agree that something that is closer to the type of scenery we can compare more easily with existing methods would be great (outdoor scenes seem indeed an interesting application).


September 20, 2000, 01:57 AM

wouter.. precomputed visibility is just that, precomputed. you can't use it with dynamic objects. try building a PVS on the fly and you'll see what i mean :)


September 20, 2000, 02:08 AM


"But when using an algorithm like progressive meshes, it can happen that there will be an edge collapsed which will result in incorrect occlusion."

If I understand you correctly, the problem you mention is that the lower resolution version must completely enclose the higher resolution version of the mesh in order for the visibility computation to be conservative.

Hugues Hoppe addresses this problem in one of his papers on progressive meshes, although I can't remember exactly which one.


Jukka Liimatta

September 20, 2000, 02:28 AM


I believe the Umbra does not do visibility per triangle but per group of triangles. Somewhere on their site it was mentioned that conservative visibility determination would be more efficient for current hardware ( faster to feed strips, than individual triangles or something to that effect ).

In this light simple bounding box for the progressive mesh should be adequate volume.

Unless, you mean, what sort of occlusion this model does *cast*, then I agree that your question makes more sense ( no simple answer to that one ;-)


Ville Miettinen

September 20, 2000, 03:06 AM

The scene in question was chosen for the following reasons:
- it can be procedurally generated on your machine (avoids transmission of a massive model dataset over the Internet)
- the models used have a reasonable number of primitives, are non-convex and contain holes
- the static portion of the scene is very hard/inefficient to present using PVS methods because the visible set varies _extremely_ quickly (same applies to several interesting real-world data sets)
- the dataset and models are way too complex for portalization (any portal traversal/clipping algorithm would just choke)
- the occlusion frontier is much too complex for any of the "select a few occluders and use them to cover the rest of the objects" algorithms (we need on average 40K occluder primitives to reach
the occlusion frontier in this scene)
- ignoring the dynamic objects as occluders would cause major occlusion volume loss
- the resulting dataset is aesthetically pleasing

We will have demos available using real-world datasets as well. However, these are likely to be shipped on CD-ROM only (for obvious reasons). Unless someone wants to donate a code that generates several gigabytes of urban environments, landscape and detail models, that is =)


Ville Miettinen

September 20, 2000, 03:14 AM

In that demo we use a separate thread for "prefetching" the object
data from the hard drive into the disk cache. We have a 1024-entry
"prefetch queue" where one can place prefetch requests (stream pointer, offset in file, number of bytes). The second thread then handles the dummy prefetching. All real loading and database updates are processed in the main thread - but the data comes from the disk cache. If the prefetch thread is lagging, we don't load the objects - this ensures that the main thread operates only on disk-cached data.


John van der Burg

September 20, 2000, 09:21 AM

That's what I mean :)
I know it doesn't do visiblity per triangle.
But it still build occlusion information from the triangles.
So in the case I mentioned things might be occluded, which should actually not be occluded :)

- John

John van der Burg

September 20, 2000, 09:27 AM

Oh cewl. I will check that out!
But I hope it are not just the border edges, which keep intact?
Because that won't be sufficient I'm afraid.

- John

Alex J. Champandard

September 20, 2000, 09:43 AM


> But I hope it are not just the border edges, which keep intact?

No, it's just an extra constraint that you apply when you generate the position of the new vertex each edge contracts to. You have to make sure all the polies involved in that edge contraction are contained within the new mesh.

It's similar to mesh simplification with volume preservation.


Ville Miettinen

September 20, 2000, 09:52 AM

If you want to provide incorrect occluder information to the system ,
you will get incorrect results. As long as the information is correct, the output is conservative and guaranteedly correct.

This means that if you use progressive meshes, you need to perform
the same updates to the occlusion subsystem. Then again, in many cases you don't want to use PM presentation for the occluders....


The Wolf

September 20, 2000, 10:12 AM

very impressive, like everyone else, it would be nice to know how it fares with outdoor scenery

One problem though, the price of the full license, $100K which is a bit high for an add-on (As I understand it, you are not selling a complete 3D engine, just the visibility determination), complete 3D engines like Quake3 are about $150K.


September 20, 2000, 01:10 PM

"complete 3D engines like Quake3 are about $150K."

LithTech, which is supposedly a cheap alternative to the Quake or Unreal engines, licenses for $250K. The big names are rumored to be at about a half a million. There certainly are cheaper engines though; I just wanted to point out that it still might be cost effective to liceses vsd technology for $100K and spend another $150k either developing or licensing the rest of the tech.


John van der Burg

September 20, 2000, 04:05 PM

No, exactly.
But it was mentioned in the documentation somewhere, and I was just thinking about it :)

- John

Jouni Mannonen

September 21, 2000, 04:34 AM

To clarify the numbers, Umbra pricing is listed on the web page at

The Basic license is $10,000 and the Professional license is $50,000. Thus, if the Quake engine licenses at half a million, you could just rip out the static PVS and replace with Umbra for just 10% more to the price. How's that for a bargain? :)


John van der Burg

September 21, 2000, 07:14 PM

Cool, thanks for the info.
Won't use it anyway, but always nice to know :)

- John

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