Jim Wilson writes:
Well I've setup a bare bones class for FGScene and have been
browsing through main.cxx. I'm not quite sure what you mean by
all of the scene- and scenery-management code.
I mean the initialization, setup (clip planes, etc.), and drawing of
the main scene graph. It
David Megginson writes:
Jim Wilson writes:
Well I've setup a bare bones class for FGScene and have been
browsing through main.cxx. I'm not quite sure what you mean by
all of the scene- and scenery-management code.
I mean the initialization, setup (clip planes, etc.), and drawing
David Megginson writes:
Curtis L. Olson writes:
My one *big* caution on this is to *think* about and pay *attention*
to opengl state management issues. If you don't have a good handle on
the subtleties involved, you could make a real mess of things or
introduce subtle rendering
On Thu, 25 Apr 2002 10:23:18 -0500 (CDT)
Curtis L. Olson [EMAIL PROTECTED] wrote:
I'm not saying this isn't an area that shouldn't be cleaned up, but I
am saying that it needs to be done ***very*** carefully.
This shouts for a decent set of regression tests, to me -
some carefully thought
Curtis L. Olson [EMAIL PROTECTED] said:
My one *big* caution on this is to *think* about and pay *attention*
to opengl state management issues. If you don't have a good handle on
the subtleties involved, you could make a real mess of things or
introduce subtle rendering bugs.
Got it.
Curtis L. Olson [EMAIL PROTECTED] said:
I'm not saying this isn't an area that shouldn't be cleaned up, but I
am saying that it needs to be done ***very*** carefully.
That's exactly what I'm planning to do Curt. I'm not interested in rewriting
this code. What I'll be doing is moving it and
Curtis L. Olson [EMAIL PROTECTED] said:
http://www.spiderbark.com/fgfs/KSFO-sinking.png
http://www.spiderbark.com/fgfs/KSFO-truman-show.png
That is strange ... are you sure you aren't changing the near/far clip
planes before you are drawing the aircraft 3d model?
Curt.
Yes it sure is
Jim Wilson writes:
Yes it sure is strange. When David moved it to the main scene graph that
fixed the problem, and just about eliminated the z-fighting between model
objects. When I get a chance I'm going to take a look at sgCullandDraw() and
the ssg source, just out of curiosity.
There's
Curtis L. Olson writes:
Jim Wilson writes:
Yes it sure is strange. When David moved it to the main scene graph that
fixed the problem, and just about eliminated the z-fighting between model
objects. When I get a chance I'm going to take a look at
sgCullandDraw() and the ssg source,
Curtis L. Olson writes:
There's nothing magic about ssgCullAndDraw() ... it just traverses the
scene graph and dumps out the corresponding opengl draw commands:
do_needed_changes();
glBegin();
do_opengl_draw_commands();
glEnd();
repeat for each leaf node.
There is really no
Norman Vine writes:
Doing the Culling and setting up the transforms for each leaf in the
Graph may be 'cheap' but it certainly isn't free and doing this multiple
times for the same geometry is usually a performance hit see below
.
No, you misunderstand. I was refering to logically
Curtis L. Olson writes:
Norman Vine writes:
Doing the Culling and setting up the transforms for each leaf in the
Graph may be 'cheap' but it certainly isn't free and doing
this multiple
times for the same geometry is usually a performance hit see below
.
No, you misunderstand. I was
Jim Wilson writes:
As a side benifit, the z-fighting within the model seems to have
reduced quite a bit once we get over the 10m AGL threshold.
Ahh...oooh...that reminds me...maybe we should make the scene's
near plane configurable per view? Fifty foot towers don't need
half meter
Norman Vine writes:
Looks OK here, as a side benefit I noticed this also brings the
framerate back up to where it was before the big reorganization too
That is a usual pattern for new features or refactoring -- first
implement, then optimize. Thanks to Norm for his contributions to the
Curtis L. Olson writes:
There is really no performance hit with using multiple ssgRoots.
Perhaps not, but there are z-buffer problems. I didn't see them as
strongly as Jim did, but the ones I could reproduce did vanish as soon
as I moved everything (except internal view in the 3D cockpit)
David Megginson [EMAIL PROTECTED] said:
Curtis L. Olson writes:
There is really no performance hit with using multiple ssgRoots.
Perhaps not, but there are z-buffer problems. I didn't see them as
strongly as Jim did, but the ones I could reproduce did vanish as soon
as I moved
Curtis L. Olson writes:
That simply can't be the case.
I agree, but nevertheless, it was.
Something else must have been changing at the same time. There
could have been state management issues, or somehow the clip planes
were actually getting changed between drawing the different
Norman Vine writes:
In the end I believe that we will have to reserve the seperate
scene graph for interior view only and integrate all other models
into the main ssg.
FWIW AFAIK This is what has been envisioned all along.
But it is rather interesting watching the path 'newcomers'
Jim Wilson writes:
This makes sense. Also I've found other reasons to not apply that
patch. The 3d model ends up disappearing behind mountains (when it
should not) if it is rendered without clearing the z-buffer.
I've just patched FlightGear to put the external plane view in the
same clip
David Megginson writes:
That may be more efficient, but it's not absolutely necessary to solve
the z-buffer problem -- we just have to ensure that in external view
everything has the same clip planes. I'm about to update the CVS to
do so.
Yes, the purpose of my 'Z-buffer 101' post :-)
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
This makes sense. Also I've found other reasons to not apply that
patch. The 3d model ends up disappearing behind mountains (when it
should not) if it is rendered without clearing the z-buffer.
I've just patched FlightGear
Norman Vine [EMAIL PROTECTED] said:
David Megginson writes:
That may be more efficient, but it's not absolutely necessary to solve
the z-buffer problem -- we just have to ensure that in external view
everything has the same clip planes. I'm about to update the CVS to
do so.
Yes, the
Jim Wilson writes:
This is what we should have for now:
acmodel.cxx FGAircraftModel::draw()
if (view_number == 0) {
glClearDepth(1);
glClear(GL_DEPTH_BUFFER_BIT);
ssgSetNearFar(_nearplane, _farplane);
+} else {
+ glClearDepth(1);
+
If you change the near/far clip planes, then what was in the depth
buffer probably should be treated as random noise following the
change. If you change the clip planes in the middle of drawing a
scene, then you really need to clear the depth buffer before doing any
more drawing.
In essence
Curtis L. Olson [EMAIL PROTECTED] said:
If that is not the case, then you will only be introducing odd
rendering effects and you probably need to come up with a different
approach.
It makes sense to change the near clip plane and clear the depth
buffer before drawing the 3d aircraft model
Jim Wilson writes:
Yes, what you have written is understood. The problems I'm seeing do not
appear to be just Z fighting and clearly have nothing to do with the near/far
plane settings. Even with fp error, it seems the problem in that second
picture shouldn't be happening.
Best,
Jim
Jim Wilson writes:
Yes, what you have written is understood. The problems I'm seeing do not
appear to be just Z fighting and clearly have nothing to do with the near/far
plane settings. Even with fp error, it seems the problem in that second
picture shouldn't be happening.
Best,
Jim
Curtis L. Olson [EMAIL PROTECTED] said:
http://www.spiderbark.com/fgfs/KSFO-sinking.png
http://www.spiderbark.com/fgfs/KSFO-truman-show.png
I just noticed part of the sky is missing in the 2nd picture, so you
must be clearing or changing something with the z-buffer.
Nope nothing like
Jim Wilson writes:
Well for the 16bit cards we need to clear the z-buffer even if we
do not set a different near/far. I tested this pretty rigorously
last night. And with the patch this morning a myriad of depth
buffer problems are appearing. They all go away when the buffer is
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
Well for the 16bit cards we need to clear the z-buffer even if we
do not set a different near/far. I tested this pretty rigorously
last night. And with the patch this morning a myriad of depth
buffer problems are
Jim Wilson writes:
Yes, I realize this. That is why I think we should try plugging externally
viewed model branches into the main scene graph.
I've just did that before opening the message -- try the latest CVS
and see if it's OK.
All the best,
David
--
David Megginson
[EMAIL
David Megginson [EMAIL PROTECTED] said:
Jim Wilson writes:
Yes, I realize this. That is why I think we should try plugging externally
viewed model branches into the main scene graph.
I've just did that before opening the message -- try the latest CVS
and see if it's OK.
Wow,
David Megginson writes:
Sent: Saturday, April 13, 2002 3:37 PM
To: [EMAIL PROTECTED]
Subject: RE: [Flightgear-devel] General issues
Jim Wilson writes:
Yes, I realize this. That is why I think we should try
plugging externally
viewed model branches into the main scene graph.
I've just did
Hi,
After not being able to compile FLightGear for about a week, I must say
FlightGear isn't improving.
I noticed several bugs/problems/annoyances:
* The scenery starts up in grayscale, and after a while turns to a
complete daylight situation. Just after e few seconds the scenery
returns
Well, I didn'T compile or run FGFS for quite a while, but
Erik Hofman wrote:
* When zooming in, form tower view, the structure of the plane gets
unstable and starts showing parts of the interior.
I think that's caused by z-buffer fighting.
So it'll be quite hard to solve in a general way.
Christian Mayer [EMAIL PROTECTED] said:
Well, I didn'T compile or run FGFS for quite a while, but
Erik Hofman wrote:
* When zooming in, form tower view, the structure of the plane gets
unstable and starts showing parts of the interior.
I think that's caused by z-buffer fighting.
Jim Wilson writes:
I'm wondering if we can cull the interior surfaces and fix this (not just the
seats, but the inside surfaces of the aircraft).
Could the interior be marked as a separate branch of the scene graph
and then somehow skipped when viewed from an external view?
Curt.
--
Curtis
Curtis L. Olson wrote:
Jim Wilson writes:
I'm wondering if we can cull the interior surfaces and fix this (not just the
seats, but the inside surfaces of the aircraft).
Could the interior be marked as a separate branch of the scene graph
and then somehow skipped when viewed from an
David Megginson wrote:
Christian Mayer writes:
So it'll be quite hard to solve in a general way. Drawing the plane last
in it's own z-buffer range (IIRC we are doing that now with the normal
3D panel) won't work generally, as there might be other objects 'in the
way' (i.e.
You are right, LOD is a better solution.
Curt.
Christian Mayer writes:
Curtis L. Olson wrote:
Jim Wilson writes:
I'm wondering if we can cull the interior surfaces and fix this (not just the
seats, but the inside surfaces of the aircraft).
Could the interior be marked as a
Curtis L. Olson writes:
Could the interior be marked as a separate branch of the scene graph
and then somehow skipped when viewed from an external view?
We wouldn't want to do that in general -- it would be OK for the 3D
instruments and controls, but if we killed the cockpit interior walls,
David Megginson [EMAIL PROTECTED] said:
Curtis L. Olson writes:
Could the interior be marked as a separate branch of the scene graph
and then somehow skipped when viewed from an external view?
We wouldn't want to do that in general -- it would be OK for the 3D
instruments and
Can we check the bounding sphere of the model and, if the viewpoint is
outside it, use the nearest point of the sphere as a candidate for the
clip plane ? Doesn't help for pilot viewpoint, but should for trailing.
David Megginson [EMAIL PROTECTED] said:
Curtis L. Olson writes:
Could
David Megginson writes:
Christian Mayer writes:
So it'll be quite hard to solve in a general way. Drawing the plane last
in it's own z-buffer range (IIRC we are doing that now with the normal
3D panel) won't work generally, as there might be other objects 'in the
way' (i.e. between the
At 4/12/02, you wrote:
Can we check the bounding sphere of the model and, if the viewpoint is
outside it, use the nearest point of the sphere as a candidate for the
clip plane ? Doesn't help for pilot viewpoint, but should for trailing.
I don't know if this is related. I have a R/C glider
Jim Wilson writes:
In the
end I believe that we will have to reserve the seperate scene graph for
interior view only and integrate all other models into the main ssg.
FWIW AFAIK This is what has been envisioned all along.
But it is rather interesting watching the path 'newcomers'
take to
Norman Vine [EMAIL PROTECTED] said:
Jim Wilson writes:
In the
end I believe that we will have to reserve the seperate scene graph for
interior view only and integrate all other models into the main ssg.
FWIW AFAIK This is what has been envisioned all along.
But it is rather
47 matches
Mail list logo
