Xojo Developer Conference
25/27th April 2018 in Denver.
MBS Xojo Conference
6/7th September 2018 in Munich, Germany.

Partially hidden polygons (Real Studio games Mailinglist archive)

Back to the thread list
Previous thread: computeBounds returns Nil for picture shapes?
Next thread: Re: Renegades navnode triggers (is again: unwanted X-ray vision)


[ANN] Preview of RBD 2.4   -   Marc Zeedar
  Partially hidden polygons   -   LMSpam neuropop.com
   Re: Partially hidden polygons   -   LMSpam neuropop.com
   Re: Partially hidden polygons   -   Jeff Quan
   Re: Partially hidden polygons   -   LMSpam neuropop.com
   Re: Partially hidden polygons   -   Joseph J. Strout
   Re: Partially hidden polygons   -   Joseph J. Strout
   Re: Partially hidden polygons   -   Jeff Quan

Partially hidden polygons
Date: 06.01.05 02:29 (Wed, 5 Jan 2005 20:29:06 -0500)
From: LMSpam neuropop.com
still wrestling w/ the x-ray vision thing...

part of the issue seems to be that my uneven landscape reveals or hides
parts of hillsides depending on camera position, so sometimes the
renderer gets confused - it will actually alternate between showing the
one that should be behind the other and not showing it...

Any ideas on how to remedy this?

For hiding other objects that appear through the landscape I've been
thinking about creating a "Ground" class which would act like the
Occluders. Does that make sense? And what would be a good way to
determine if a hillside is between the camera and the object?

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Partially hidden polygons
Date: 06.01.05 06:15 (Thu, 6 Jan 2005 00:15:42 -0500)
From: LMSpam neuropop.com
thanks.... I've actually been working on upping the navMesh count. It's
working better, though for some weird reason there's one place where
the mesh drops a couple of units below the hilltop it's supposedly
tracking... gonna try hand editing the .levl file. I really like the
idea of floating over sections, and if another problem pops up, I think
I'll try putting in more of the irritable tree forest.

After that, I'll put back the occluders,.



On Jan 6, 2005, at 12:46 AM, Jeff Quan wrote:

>
> On Jan 5, 2005, at 5:29 PM, <email address removed> wrote:
>> still wrestling w/ the x-ray vision thing...
>> part of the issue seems to be that my uneven landscape reveals or
>> hides parts of hillsides depending on camera position, so sometimes
>> the renderer gets confused - it will actually alternate between
>> showing the one that should be behind the other and not showing it...
>
> Here are some ideas for you:
> You could set the navmesh higher than the actual terrain. That way
> there's less of a chance for the camera to poke through.
> Another thing you could try is to smooth your terrain so that there
> aren't too many steep hills to run into.
> Finally, You could also edit the navmesh so that the navmesh itself is
> shallower than the actual terrain (ie: if it's a steep valley, make
> the navmesh a less steep valley). Since you're creating an abstract
> world, you can get away with floating a bit over areas. If you're
> clever enough in editing the navmesh, perhaps no one will even notice.
>
>> For hiding other objects that appear through the landscape I've been
>> thinking about creating a "Ground" class which would act like the
>> Occluders. Does that make sense? And what would be a good way to
>> determine if a hillside is between the camera and the object?
>
> Given what I've seen in your alpha, the occluders should work just
> fine. While you may not want to limit the user's movement, you could
> create areas where users have to go around obstacles. By limiting
> where users can walk, you can more effectively place occluders to
> maximum effect.
>
> => Jeff Quan
> <email address removed>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Partially hidden polygons
Date: 06.01.05 06:46 (Wed, 5 Jan 2005 21:46:30 -0800)
From: Jeff Quan

On Jan 5, 2005, at 5:29 PM, <email address removed> wrote:
> still wrestling w/ the x-ray vision thing...
> part of the issue seems to be that my uneven landscape reveals or
> hides parts of hillsides depending on camera position, so sometimes
> the renderer gets confused - it will actually alternate between
> showing the one that should be behind the other and not showing it...

Here are some ideas for you:
You could set the navmesh higher than the actual terrain. That way
there's less of a chance for the camera to poke through.
Another thing you could try is to smooth your terrain so that there
aren't too many steep hills to run into.
Finally, You could also edit the navmesh so that the navmesh itself is
shallower than the actual terrain (ie: if it's a steep valley, make the
navmesh a less steep valley). Since you're creating an abstract world,
you can get away with floating a bit over areas. If you're clever
enough in editing the navmesh, perhaps no one will even notice.

> For hiding other objects that appear through the landscape I've been
> thinking about creating a "Ground" class which would act like the
> Occluders. Does that make sense? And what would be a good way to
> determine if a hillside is between the camera and the object?

Given what I've seen in your alpha, the occluders should work just
fine. While you may not want to limit the user's movement, you could
create areas where users have to go around obstacles. By limiting where
users can walk, you can more effectively place occluders to maximum
effect.

=Jeff Quan
<email address removed>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Partially hidden polygons
Date: 06.01.05 15:02 (Thu, 6 Jan 2005 09:02:15 -0500)
From: LMSpam neuropop.com
Commenting out the cull routines didn't do much except to up the
rendering time in the Profiler window.
What I'm seeing right now sounds very much like what you mention with
the Linux boxes - far away polygons being drawn in front of nearby
ones. I can actually test on Windows and Linspire Linux if I remove the
MoviePlayer.

I'm glad creating a "Ground" class is not a good idea at this stage -
thinking about it made my brain hurt.

If this gets too hard I'll try Jeff's idea of smoothing the landscape -
upping the navMesh count helped, but still not perfect.

If I get the time, I'll post where I'm at later this afternoon with the
source

On Jan 6, 2005, at 9:50 AM, Joseph J. Strout wrote:

> At 8:29 PM -0500 1/5/05, <email address removed> wrote:
>
>> still wrestling w/ the x-ray vision thing...
>
> What did you find from disabling frustum culling or occlusion culling?
>
>> part of the issue seems to be that my uneven landscape reveals or
>> hides parts of hillsides depending on camera position, so sometimes
>> the renderer gets confused - it will actually alternate between
>> showing the one that should be behind the other and not showing it...
>
> There's a bug somewhere, and almost certainly not in the renderer.
> Unless, perhaps, your yon/hither ratio is simply too large. You're
> currently using Hither(which actually means Hither1; it's
> impossible to have a hither of 0.0). Try setting Hitheror even
> HitherP just to see if that changes it. (This is for the problem of
> seeing through walls that are a good distance away from the camera --
> obviously a larger Hither will allow you to poke through nearby
> objects more, but that's a different problem.)
>
>> For hiding other objects that appear through the landscape I've been
>> thinking about creating a "Ground" class which would act like the
>> Occluders. Does that make sense?
>
> Not at this stage. The problem you have currently is objects
> disappearing when they shouldn't, as I understand it. Making more
> stuff disappear, and making the code more complex, isn't going to help
> track down the bug.
>
> Actually, it does occur to me that it might be a renderer problem. We
> have seen an issue on Linux where objects are rendered inside-out on
> some machines; that is, polygons behind are drawn on top of polygons
> in front. It's a very bizarre effect. I've never seen that on a Mac
> or Windows box, though. What platform are you running on, and can you
> test on something else? What about testing under Mac Classic using
> QD3D, for example?
>
> Best,
> - Joe
>
> --
> REAL World 2005 - The REALbasic User Conference
> March 23-25, 2005, Austin, Texas
> <http://www.realsoftware.com/realworld>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Partially hidden polygons
Date: 06.01.05 15:50 (Thu, 6 Jan 2005 08:50:15 -0600)
From: Joseph J. Strout
At 8:29 PM -0500 1/5/05, <email address removed> wrote:

>still wrestling w/ the x-ray vision thing...

What did you find from disabling frustum culling or occlusion culling?

>part of the issue seems to be that my uneven landscape reveals or
>hides parts of hillsides depending on camera position, so sometimes
>the renderer gets confused - it will actually alternate between
>showing the one that should be behind the other and not showing it...

There's a bug somewhere, and almost certainly not in the renderer.
Unless, perhaps, your yon/hither ratio is simply too large. You're
currently using Hither(which actually means Hither1; it's
impossible to have a hither of 0.0). Try setting Hitheror even
HitherP just to see if that changes it. (This is for the problem
of seeing through walls that are a good distance away from the camera
-- obviously a larger Hither will allow you to poke through nearby
objects more, but that's a different problem.)

>For hiding other objects that appear through the landscape I've been
>thinking about creating a "Ground" class which would act like the
>Occluders. Does that make sense?

Not at this stage. The problem you have currently is objects
disappearing when they shouldn't, as I understand it. Making more
stuff disappear, and making the code more complex, isn't going to
help track down the bug.

Actually, it does occur to me that it might be a renderer problem.
We have seen an issue on Linux where objects are rendered inside-out
on some machines; that is, polygons behind are drawn on top of
polygons in front. It's a very bizarre effect. I've never seen that
on a Mac or Windows box, though. What platform are you running on,
and can you test on something else? What about testing under Mac
Classic using QD3D, for example?

Best,
- Joe

Re: Partially hidden polygons
Date: 06.01.05 16:51 (Thu, 6 Jan 2005 09:51:11 -0600)
From: Joseph J. Strout
At 9:02 AM -0500 1/6/05, <email address removed> wrote:

>If this gets too hard I'll try Jeff's idea of smoothing the
>landscape - upping the navMesh count helped, but still not perfect.

The nav mesh shouldn't affect rendering at all, unless the problem is
that you're actually poking yourself right through the landscape.
From earlier discussions, I thought that wasn't the case. But if the
navmesh matters, then I'm not so sure.

What if you delete the nav mesh entirely? In that case, you can
freely move the camera anywhere you want (though only in whatever XZ
plane you start in; there are no controls for moving it up and down).
In that case, if you take care to make sure you're not actually
inside a hill or some such, what do you see?

Best,
- Joe

Re: Partially hidden polygons
Date: 06.01.05 17:48 (Thu, 6 Jan 2005 08:48:30 -0800)
From: Jeff Quan
On Jan 5, 2005, at 9:15 PM, <email address removed> wrote:
> thanks.... I've actually been working on upping the navMesh count.

You don't really need to up the navMesh count too much or add more
polygons to the terrain. What I'm suggesting is if your terrain has
some area which is a steep valley/crevasse/gully like:
<ASCII art begin>

\ /
\ /
\/

your navmesh could be:

\ /
\_/

<ASCII art end>

Thus the player may see a "V"-shaped valley, but the navnodes allows
only a "U"-shaped path. Or there could still be a "V"-shaped navmesh
but made shallower than the terrain (no new navnodes needed).

The other alternative is to make the valley shallower by taking all
those vertices which are at the bottom of the valley and moving them up
the Y axis to create shallower valleys and thus no additional polygons
or navnodes are created.

> It's working better, though for some weird reason there's one place
> where the mesh drops a couple of units below the hilltop it's
> supposedly tracking... gonna try hand editing the .levl file. I really
> like the idea of floating over sections, and if another problem pops
> up, I think I'll try putting in more of the irritable tree forest.

That can indicate an errant navnode in your level file. You might want
to check if there are navnodes atop navnodes. If you used the Renegades
Navbuilder to create your navnodes, it doesn't always do a good job of
detecting duplicates and may place two identical navnodes where there
should be just one. I wrote just enough to get it working and didn't
bother to finesse it past that point.

Also note that a navnode must be built in a clockwise fashion.

=Jeff Quan
<email address removed>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>