Ogre Forums

Hi !

Is there a default approach to making "holes" into the the heightfield based terrain to connect it to some underground dungeon, created as a normal mesh or static geometry?

I guess using portals would be a good way, but portals don't seam to be ready for use, according to this thread http://www.ogre3d.org/phpBB2/viewtopic. ... 58&start=0 .

So are there other ways to do it?

-
Marc

I think you'd be best just to poke some solid geometry through it and slap a portal on the front (or a little way down the hollow section). You'd need a SceneManager that can handle portals of course...

Portals would be the best approach for this, but another possible trick is to write geometry to the depth buffer but not to the colour buffer where you want to "cut" the whole, prior to rendering the terrain. Then render the terrain and it won't render where the hole geometry was rendered.

Falagard

Falagard wrote:Portals would be the best approach for this, but another possible trick is to write geometry to the depth buffer but not to the colour buffer where you want to "cut" the whole, prior to rendering the terrain. Then render the terrain and it won't render where the hole geometry was rendered.

Falagard

to zbuffer-writing:
I thought of this zbuffer-writing way. But is it possible to doe that by defining just special materials? Or do I have to call some lower-rendering-methods myself?

E.g. if I just put an additional object in the scene with a material that writes zbuffer values somehow and ignores testing against the current zbuffer values. Then how can I be sure that this object, the underground dungeon and the terrain get drawn in the right order so that it looks right?

to portals: s. Chasters thread

I am working on a portal scene manager of my own, and have thought about this... I also thought of rendering an invisible quad to the depth buffer to make holes in terrains (for use of a portal)... I figured that, you would have to draw the underground first, then the invisible quad, than the terrain... You'llhave to ensure that the objects get drawn in the right order, which probably requires that they have different renderque priorities.

One drawback though, is overdraw... Since the terrain has not been drawn yet,there is no clipping performed on the underground, and then the terrain will just get drawn over parts that should not have been visible. In my case, I will use the portals edges to affect clipping, so there will not be lots of overdraw.

Though, I have not tested this yet as I have been working on other things so far.

Alternatively you can hack the scene manager to leave holes in the terrain by modifying the index buffers. The holes would probably have to be the same size as the quads at lowest LOD for simplicity. This is probably a more complicated solution than the z-buffer approach. I think this is how they made holes in the terrain in e.g. FarCry.

[quote="pjcast"]I am working on a portal scene manager of my own, and have thought about this... I also thought of rendering an invisible quad to the depth buffer to make holes in terrains (for use of a portal)... I figured that, you would have to draw the underground first, then the invisible quad, than the terrain... You'llhave to ensure that the objects get drawn in the right order, which probably requires that they have different renderque priorities.
[/quota]
That only works correctly if you look from the terrain inside the underground. But if you look from the underground outside, you get wrong results. I guess you have to switch renderqueue priorities depending on where you are then.

@DWORD: Are you sure? I don't know, but I always thought they use portals in FarCry. They need them anyway to connect their different scenetypes efficiently. To your hole cutting method: Don't you get problems when the quad that you don't draw gets further away and together with the surrounding quads gets rendered in a lower LOD level? Then you would have to ignore that larger quad completely, what is obviously wrong, or you can draw it, closing the hole, what is also wrong. Or do I miss something?

Marc wrote:@DWORD: Are you sure? I don't know, but I always thought they use portals in FarCry. They need them anyway to connect their different scenetypes efficiently.

I'm quite sure this is how they make their holes in the terrain, but I don't know for sure either. Ofcourse they probably also use portals for the 'entrance' through the cut holes, and for their interiors. I just noticed that in their map editor, you could use a tool that removed/restored quads of the terrain by clicking. Then in their levels they placed some entities on those holes that covered the ugly edge and made a smooth transisition to interior.

Marc wrote:To your hole cutting method: Don't you get problems when the quad that you don't draw gets further away and together with the surrounding quads gets rendered in a lower LOD level? Then you would have to ignore that larger quad completely, what is obviously wrong, or you can draw it, closing the hole, what is also wrong. Or do I miss something?

That's why I wrote "the same size as the quads at lowest LOD". The hole should be defined so that there are no lower LOD levels, i.e. for higher levels of detail more quads would be invisible for the same hole. I don't think this is too hard to achieve. For example you could have a map specifying (in)visible quads, and then when building the index buffers you check against that and just skip the quads that should be invisible.

Edit: But yeah, depending on the number of mipmap levels, the quads can get quite large, so this may not be optimal. Maybe some middle course would do the trick; when things are far enough to use lowest LOD, it probably doesn't make significant visible difference whether you render the terrain at the hole or not. I don't have FarCry installed right now, so I can't check how they do it unfortunately.

Well, this really sounds like big holes. But perhaps that would be the better approach than rewriting the zbuffer anyway.

Is the FarCry Editor freely available via download? Or is it packaged in the box. I've only the demo that does not include the editor (surprise, surprise ).

I don't know which method is easiest. It's probably using the z-buffer, but I don't know how much overhead the overdraw would cause.

The editor is packaged with the game. I can try installing it to see how they do it...

Marc wrote: That only works correctly if you look from the terrain inside the underground. But if you look from the underground outside, you get wrong results. I guess you have to switch renderqueue priorities depending on where you are then.

Nope... If you look from under the terrain, the terrain is not drawn because of backfacing triangles... and in my case, with portals, it is the reverse of what happened before... The destination sector would be drawn first, than the current sector, in this case would be terrain, then whatever type of sector I'm in

Just checked how they did it in Far Cry. They're cheating. It appears they cut quad holes at the highest LOD, and then just ignore them for lower LODs, effectively capping the hole. This is from the editor with and without 'brushes':



Here are shots with high/low LOD; notice the capped hole:

That makes sense though, if you were far enough away to be in the 2nd lod, you probably won't be looking too closely at the entrances
and if they stick them out enough from the terrain it would be unnoticable

Yep, it's not very noticeable when far away. A simple way to overcome artifacts (visible errors?) would be to have a lower LOD version of the entrance too where the hole was capped, maybe with some texture looking like the interior, or not rendering the entrance at all. Then it wouldn't be necessary to render the interior.

pjcast wrote:Nope... If you look from under the terrain, the terrain is not drawn because of backfacing triangles... and in my case, with portals, it is the reverse of what happened before... The destination sector would be drawn first, than the current sector, in this case would be terrain, then whatever type of sector I'm in

But this only holds if you have some special subset of all possible terrains. It could be possible that you look from inside your underground-dungeon, through the entrance onto some mountain. This mountain has to be drawn and does not get rejected because of backface culling.

DWORD wrote:Yep, it's not very noticeable when far away. A simple way to overcome artifacts (visible errors?) would be to have a lower LOD version of the entrance too where the hole was capped, maybe with some texture looking like the interior, or not rendering the entrance at all. Then it wouldn't be necessary to render the interior.

But that way, they can't have large entrances right? Only some of the size of the smallest Quad. Did they really limit themselves that way? Can you remove 2 or more neighbouring quads in the editor to make larger entrances? What happens then if you switch the lod level? Does the bigger entrance disappear too even though the cheating gets clearly visible?

Marc wrote:

pjcast wrote:Nope... If you look from under the terrain, the terrain is not drawn because of backfacing triangles... and in my case, with portals, it is the reverse of what happened before... The destination sector would be drawn first, than the current sector, in this case would be terrain, then whatever type of sector I'm in

But this only holds if you have some special subset of all possible terrains. It could be possible that you look from inside your underground-dungeon, through the entrance onto some mountain. This mountain has to be drawn and does not get rejected because of backface culling.

I'm sorry, but I'm not following you logic...

If I understand what you are saying... you have a mountain underground?... that has a portal that is looking out into the terrain... it would be terrain (destination), invisble portal, than current sector (mountain and underground).

Marc is sitting in his underground dungeon looking at a mountain outside.
((That mountain is of course part of the terrain))

They can have larger entrances by removing more neighbouring quads as they do in the screenshot. Yes, I think they really did limit themselves that way. They completely ignore the holes for lower LOD, but ofcourse that limits the usability.

jacmoe wrote:Marc is sitting in his underground dungeon looking at a mountain outside.
((That mountain is of course part of the terrain))

If that is the case... it still works... it's not a matter of rendering something, than portal, than terrain... It is a matter of rendering the destination, the portal, then the current sector.. Regardless of whether or not terrain is even involved.

So, in this example: outside terrain - including mountains... than the portal, than the current underground sector... I don't see how there is a problem.

pjcast wrote:

jacmoe wrote:Marc is sitting in his underground dungeon looking at a mountain outside.
((That mountain is of course part of the terrain))

If that is the case... it still works... it's not a matter of rendering something, than portal, than terrain... It is a matter of rendering the destination, the portal, then the current sector.. Regardless of whether or not terrain is even involved.

So, in this example: outside terrain - including mountains... than the portal, than the current underground sector... I don't see how there is a problem.

Ah ok, that's what I meant with "I guess you have to switch renderqueue priorities depending on where you are then.".

sinbad wrote:I think you'd be best just to poke some solid geometry through it and slap a portal on the front (or a little way down the hollow section). You'd need a SceneManager that can handle portals of course...

... that can be downloaded here http://www.ogre3d.org/modules.php?op=mo ... 57ae08a338

Do you know more details about Chasters code? I posted to his thread but noone reacts. Do you have some, at least semi working code of it? Do you still think adding a general portal concept that primarily allows for mirrors and such effects is the best way or just writing some custom portal scene manager (and then some custom scene managers that can handle several rendering algorithms itself and also connects them by itself through selfdefined portals)?