[FireCrack]

I noticed on nicos perseus that the guy and cockpit are a different submodel than the hull and glass, is this necessary, and why?

[Nuke]

subobjects get rendered first, and transparency should be rendered on top of that.  i usually put the transparency in the ship texture. your cockpit and pilot should be rendered first and then the ship, and im ny case it is.

you can have a seporate subobject for the glass, if you want a cockpit that can be opened, but you gotta make sure the textures for that subobject come before the interior. theres really no reason to make an openable cockpit, but with the in-game cutsceene features it might be usefull someday.

[FireCrack]

If i have supports going around my cockpit, should the inside facing faces of these be part of the cockpit submodel?

[Nuke]

yea probibly. i wouldnt make the internal window panes of the cocpit model transparent. that could have unforseeable problems. all exterior in the hull model, all interior in the cockpit model.

[FireCrack]

K, thanks nuke!

Thery'l be an erynies yet!

[karajorma]

I'm no modeller but from what I've picked up Bobs Herc is the better way of doing glass than Nico's Perseus.

[aldo_14]

IIRC it's best to use a seperate transparent map for the cockpit; I think Bob said there could be rendering order problems otherwise (depending on subobject rendering).  If you don't care about opacity, etc, gradients then you can use a miniscule 1x1 map.

[StratComm]

Actually making the cockpit glass a seperate submodel is a bad idea in almost all respects.  If it's a bubble cockpit like the one on the Myrmidon then you might get away with it, but if it's possible to look through the glass at another part of the ship (like a wing or something) then that piece won't get rendered.  Glass (or any other transparent object, like nameplates) should be the last textures on the primary hull, without exception.  Now the necessity of the cockpit model being a seperate submodel is another question entirely, but since it takes its own map then it probably doesn't matter all that much.

[FireCrack]

ok, now i'm confused...

[StratComm]

What, the contradictory advice?

Take my word on this, I know the basics of how the engine works and have successfully fixed transparency problems for a few well-respected people in the past.  The glass needs to be part of the main hull.

[FireCrack]

Ok, yeah i know that part but my cockpit has little support beams going around it, should the inside facing parts of these be part of the cockpit model or what?

[StratComm]

The short answer is that it depends.  

The longer answer is that it actually has more to do with the mapping than the model itself.  If the inside of the struts are part of the cockpit map, then make them part of the cockpit.  If they are part of the hull map, make them part of the hull.  If you haven't yet mapped either, I'd say make them part of the hull so you don't have to mess with the existing cockpit map.

[aldo_14]

Originally posted by StratComm
Actually making the cockpit glass a seperate submodel is a bad idea in almost all respects.  If it's a bubble cockpit like the one on the Myrmidon then you might get away with it, but if it's possible to look through the glass at another part of the ship (like a wing or something) then that piece won't get rendered.  Glass (or any other transparent object, like nameplates) should be the last textures on the primary hull, without exception.  Now the necessity of the cockpit model being a seperate submodel is another question entirely, but since it takes its own map then it probably doesn't matter all that much.

(is that @me?)

Having checked my own model (which works perfectly; can see in the cockpit, can see bits of the ship out of the cockpit), I found the following setup;
- main hull (including glass of canopy) is a subobject.  Internal cockpit+pilot is a subobject
- Canopy uses a glass texture seperate from the texture used for the rest of the hull model.  I had the glass texture (with alpha) as part of the hull texture at one point, and this caused errors with transparency, IIRC mainly not seeing the hull from in-the-cockpit view.

[StratComm]

Nope aldo, that was not directed at you.  It was in response to what Nuke said earlier up the thread.  You're spot-on with how to do it.  

Also, I was frankly not sure how having the glass as part of the map would work, but I've always considered that a needless addition of an alpha map to an already large texture.  And besides, you almost invariantly want the geometry to conform to the edges of the glass, so you don't see through gaps when looking at the seam between the cockpit and the hull proper.

[Nuke]

well it is, regaurdless not something you should do, but if you want an animated opening cocpit it could be done that way. but like i said there is really no reason one would need to do that now. its just a matter of knowing in which order things will get rendered and working your texture order or subobjects so that all things get rendered when they should.

ive made cockpits for 3 ships so far, pf chimera, pf shagrath, and pf satyr.

the chimera uses 2 textures, a glass texture which is applied to the windows, and a hull texture which is shared between the cockpit interior and the hull. the interior of the struts is part of the interior model. transparency works perfectly.

shagrath uses only one texture for the ship and glass, i found so long as the uv space for the glass is seprate from things that are not transparent, you should have no problem. this way you dont accidently make something transparent that shouldnt be. it is a simple bubble cockpit with no struts.

the satyr's cockpit is probibly my best one, it was so effietiently uv mapped that it needed a second texture for the interior, however i squeezed in the glass into the same texture as the hull (it was originally mapped seprate from the non transparent polies so i didnt have to change anything), thus eliminating the need for another texture pass.

one texture pass per subobject is suffietent. if you put your trans in another texture it will slow down htl. if you are using dxt5 you still get a 4x compression ratio.  its better to put the transparency in the same texture as the hull and save a pass. but like i said keep the uv space on polies that should be transparent seprate from those shat should not be.keep the transparent stuff in a seprate section of the uv space..

[StratComm]

Why anyone would ever want to make a cockpit open in the middle of a space sim confuses me greatly, but that is not and never was my point.  The flaws with making the glass a seperate subobject (and possibly part of the main texture, though it gets really messy there) are that instead of displaying parts of the primary hull through the glass (from outside, looking through the cockpit at some other part of the ship) those sections behind the cockpit glass will dissapear.  It is possible that "having a seperate UV space" means those polys get drawn later, but tweaking your model for that to work everywhere isn't something that can reliably be done.  As long as the cockpit interior is a subobject and the glass is part of the main hull, rendering of the cockpit will always work.  However, that's not everything to the transparency, and in fact may make you think that everything works fine without you actually looking at everything that could be hidden behind the glass.

And as I said, having the cockpit glass part of the hull map may work some of the time, but then again it may not.  If you are just learning the technique then don't do it that way, as you'll probably be frustrated down the road thinking that you're doing it correctly.  And one texture vs. two textures on LOD0 of a fighter (which should transition to LOD1 VERY quickly, as the high-poly cockpit isn't visible from very far away) is really a trivial difference and not one to invoke the map rules for HTL over.

[KARMA]

Q: can you define the cockpit so that it is visible only very close? I mean, whithout using 2 different lods...
You can use bob's detail box, but what happen then with the transparency?

[StratComm]

That'd look pretty horrible, IMHO.  The cockpit would vanish and you could see right through the glass to a hole in the ship.  If you tried to make the glass a detail box, it would cease to work correctly as a primary hull transparency.  The best solution would be to have an exact copy of LOD0 as LOD1, just without the cockpit and with the glass mapped black.

[Nuke]

Originally posted by StratComm
Why anyone would ever want to make a cockpit open in the middle of a space sim confuses me greatly, but that is not and never was my point.  The flaws with making the glass a seperate subobject (and possibly part of the main texture, though it gets really messy there) are that instead of displaying parts of the primary hull through the glass (from outside, looking through the cockpit at some other part of the ship) those sections behind the cockpit glass will dissapear.  It is possible that "having a seperate UV space" means those polys get drawn later, but tweaking your model for that to work everywhere isn't something that can reliably be done.  As long as the cockpit interior is a subobject and the glass is part of the main hull, rendering of the cockpit will always work.  However, that's not everything to the transparency, and in fact may make you think that everything works fine without you actually looking at everything that could be hidden behind the glass.

And as I said, having the cockpit glass part of the hull map may work some of the time, but then again it may not.  If you are just learning the technique then don't do it that way, as you'll probably be frustrated down the road thinking that you're doing it correctly.  And one texture vs. two textures on LOD0 of a fighter (which should transition to LOD1 VERY quickly, as the high-poly cockpit isn't visible from very far away) is really a trivial difference and not one to invoke the map rules for HTL over.

you have no vision for the future man! with people doing ship interiors and detailed fighter bays i was thinking that eventually there would be a character animation system, and you could have briefings and such rendered as part of the engine, then see pilots running to their fighters and jump in, close tha canopy and fly off. and i dont think any other game has done it that way, freelancer came close but didnt pull it off to my satisfaction. in theory the opening cockpit could work, but it would be a total waste of time at the moment. i agree it is a stupid idea, especially for those who are not yet comfortable with cockpits.

regaurdless putting the glass in the hull texture does work, ive yet to encounter a situation in which it doesnt. the only reason i dont see it working is that if you have more than one texture on the hull object, and the texture with the transparency is not the last of the hull textures on the list. for maximum htl performance i like to stick to the one texture per object rule and if you follow that rule, putting the trans in the hull texture does work. polies render back to front so if you have glass in front of some other part of the ship the glass will get rendered over it and it will look ok.

[Bobboau]

StratComm 's been prety much right on, origonaly I sugested, makeing the class as a seperate subobject, because I thought it might be too triky to get the textures in the corect order, but if you can get it done, this is the better method. he is wrong about the detail box thing though, they can be set up so that a subobject is or is not rendered based on it's position in the box, so you can have a high and low detail cockpit, or more simply, just have all the detailed bits in a seperate subobject that the hole it sits in.

Nuke is corect in that fewer textures == fewer passes == faster == better, however, puting transparency on the same map as will be seen through the transparency is asking for trouble, it might work, it might not, it's what's refered to in the computer science world as 'undefined behavior' there is no way to know in what order the polies will be drawn, keeping them to one part of the texture will make no diference at all. currently, the polies are drawen in what ever order the BSP compiler happened to make it's tree, there is no definition on how this is done, so there is no way to setup the polys so they draw corectly, though you might get lucky. in the future you will have the option of determineing the draw order of polygons in a texture, you will have the options 'front to back' (for non-transparent textures), 'back to front' (for transparent textures) and 'none' (can be faster than resorting for non-transparent).