[StratComm]

I know this is a known problem, but I realized there was another use for "show ship" besides the player craft.  Unfortunately, this is the result:


Is there no better way of doing this than making the ship about 100 times its correct size?

[Taristin]

I don't think I understand what you're showing here...

[StratComm]

I'm viewing from a corvette, with "show ship" active (so it's as though you're looking out from the bridge).  It should be occluding everything, but instead a cruiser and a corvette and a half are rendering through the ship I'm supposed to be viewing from.  It's the half-corvette on the right that makes me think it's not z-buffer related, since it's getting clipped off quite neatly.  My question is why.

[WMCoolmon]

Try using -clipdist with an argument of "0.05" (no quotation marks)

[StratComm]

What's the tradeoff though?

EDIT: I see it.  That makes all of my nameplates flickery.

[WMCoolmon]

Stuff further awaylooks worse, but I think it might fix the problem.

Edit: does it fix it?

[StratComm]

Yeah, it fixes it.  But nameplates are not consistantly rendering on top of the hull, even though they are a quarter-meter or so outside of the hull geometry, until I'm ~100 meters away.  That's more important.  Why is the ship model rendered with such a high clipping distance, anyway?

[WMCoolmon]

It used to be 1.0f, but that was causing trouble with cockpits.

There are a couple options I guess.

1- figure out some way to draw the cockpit without changing the clipping distance. Maybe enlarging the model and changing the FOV, though that would look a bit odd.
2-There is no two, yet.

[StratComm]

Originally posted by WMCoolmon
1- figure out some way to draw the cockpit without changing the clipping distance. Maybe enlarging the model and changing the FOV, though that would look a bit odd.

That's why I'd like to see seperate cockpit models that are only rendered when you're looking through the cockpit.  For the most part, "show ship" is being used to render out only the cockpit, as unless you get into padlock view none of your ship is visable anyway.  So why not render both the ship (for the external bits that you can see) as well as a dedicated user cockpit, which could be 2x-8x normal size so that it doesn't clip off.  As long as it's centered around the eye, perspecive wouldn't be an issue.

[WMCoolmon]

I don't have the maths before me to check it, but I don't think that would work. The clipping plane *can't* be changed, so that means the cockpit and/or player ship would have to be drawn on top of it. That means drawing the player ship elements afterwards, but I don't think it's possible to instruct FS to render ships on top of the current set - unless perhaps you render all the other ships first and then clear the zbuffer, then render the player ship/cockpit.

And of course if you're rendering the ship and cockpit afterwards, anyway, the clipping distance might as well be set to 0.05 for both, so they could be rendered at normal size.

[StratComm]

I'm not thinking of anything nearly that complicated.  I'd have to check, but I'm pretty sure that everyone is making their cockpits a seperate submodel, and then inside the ship, where the eye is, all of the primary geometry elements are backfacing and will get culled.  So you set a flag in the POF data for the pilot/cockpit subsystem that tells the game not to render that subsystem when viewing from this ship.  Then you have a seperate cockpit chunk that just contains the visable cockpit at some larger scale (as to avoid clipping) that can be rendered only when viewing from this ship.  As long as the player cockpit model doesn't bound past a visible ship component, the z-buffer should keep it on top.  Is that feasable, or am I misunderstanding what limits you can set on making subobjects renderable.

[WMCoolmon]

Well, part of the problem is that in my initial post on it I said just the opposite, the model would have to be made smaller...larger would just make the problem worse. And if you make it smaller, then you just make everything closer to the ship, and you end up with the same problem as before.

It should be fairly easy to render the player ship last. I don't think that'll clear up the problem without wiping the 3D data on stuff already drawn to the backbuffer, but I can try it.

This should also clear up a problem aldo reported.

Edit: rendering specific subobjects last would actually be more difficult. There's actually a render_ship function which is called from render_all_ships or something similar, I just have to make it get called at the end of the 'all' function or after all 3D objects have been rendered.

[StratComm]

I thought it was a near clipping plane issue, which is why I was thinking to have a larger player cockpit model than the actual cockpit is on the ship.  If it's not a near-plane problem, then I'm chasing down the wrong problem.  This isn't a huge problem, as this was just something I was playing with, so don't let it seem like I'm asking for a complete rework or anything.  If it's not easily fixed, don't worry about it.

EDIT: Didn't even think about having to render out a subsystem last.  That could be very problematic, actually.  Could the cockpit be a seperate POF?

[Deepblue]

Will the clipdist thing make it so effects do not render OVER the cockpit and the cockpit model will not sink into objects I crash into?

[Kazan]

it should be possible to clear the transform stack and re-init it with same FOV but differen't clip distances

i know you can do that in OpenGL

-----------

"Start frame"
load identity marticies
glFrustrum
render.
render..
render...
reach player ship
pushMatrix()
load identity matricies
glFrustrum
render player ship
popMatrix()
render.
render..
render...
"Finish Frame"

------------

that's how you switch between the 2d-hud-rendering coordinates and the 3d-object rendering coordinates (but you wait until all 3d is done and then render the 2d hud objects)


unless fs2 does the 2d-rendering in some strange way it should be changing basic projection mods twice each frame - initially setting it for 3d, then changing it for 2d

[WMCoolmon]

Yeah, that was along the lines of what I was thinking.