some polys rendering out of turn?

FSIC Messageboard

Tech Talk

profile | register | preferences | faq | search

UBBFriend: Email This Page to Someone!

next newest topic | next oldest topic

Author	Topic: some polys rendering out of turn?
charmstar Pilot	posted 02-27- 02:45 AM Here's my latest question. I have a couple of fuel tanks positioned just a few inches behind the cockpit panel in teh BleriotXI. Unfortunately, these fueltanks seem to render in front of the panel in SDOE, even though they are behind it. Also, behind the fueltanks is a bulkhead, and that occasionally renders in front of the tanks too! Has anybody seen this, or know how to fix it? charm IP: Logged
Laika 801 Pilot	posted 02-27- 04:49 AM What grafik card did you got ? I got similar problems with some detail lods (mostly polys with small space between). I figured out that even when I move the polys about 0,2 feet the problem still is there. I use a TNT2 card. IP: Logged
Bryan Russell Pilot	posted 02-27- 05:06 AM I suspect that this has to do with the resolution of the Z-Buffer. If this is the case then close up it will look right but further away it will show through. In the poly flags there is stuff just built to handle this. Its called subface nesting. Basically you either disable it by setting a value of 0 or set the poly that you need to draw on top with a subface nesting value higher than the other poly. To set the subface nesting in the poly flags you might have to manually edit it in a LOD file or you can use the MAX material naming convention and OPS. IP: Logged
Laika 801 Pilot	posted 02-27- 08:47 AM Thanks Bryan - but I´m afraid I din´t understand what to do - PLEASE can you outline the steps for this ??? THANKS ! LK IP: Logged
Sv Pilot	posted 02-27- 09:08 AM Hmmm, I wonder if this has to do with my latest problem as well, please read my "help me! 3d issues" post... -Sv IP: Logged
JT Pilot	posted 02-27- 10:16 AM Charm, look at the LODs of the instrument panels of any plane. Since the gauges are flush with the panel, you have to tell SDOE to draw the gauge as if it's on top. There is a polyflag in the LOD that let's you do this.... for example... if the instrument panel has a flag of 08, you will want the gauges to have a flag of 18. The needles are supposed to be on top of the gauges, so they would get a flag of 28. IP: Logged
JT Pilot	posted 02-27- 10:19 AM By the way, look at SV's Openplane site. Check out his "Anatomy of a LOD" section. That will show you where the polyflag is. IP: Logged
Laika 801 Pilot	posted 02-27- 01:17 PM JAAAAAAA !!! It works ! GREAT ! FINE ! MUCH THANKS ! LK ! IP: Logged
Laika 801 Pilot	posted 02-27- 02:44 PM "Basically you either disable it by setting a value of 0 or set the poly that you need to draw on top with a subface nesting value higher than the other poly" so I did that - (set the flag to 82/01010010 for the upper poly and 50/00110010 for the other poly - in OPS all looks fine but in SDOE I can´t see the polys with flag set to 82 (did I calculate something wrong ?). So I set all polys to 50 (=subfaced) and now it also works in SDOE - thats fine but I dont understand it anymore. IP: Logged
Bryan Russell Pilot	posted 02-27- 06:01 PM Probably becuase 01010010 is actually 62 not 82, 82 would turn on the point mode which would only draw the points of the poly, not the actual poly. OPS doesn't support this bit so that's why it looks fine there. IP: Logged
Bryan Russell Pilot	posted 02-27- 09:56 PM Whoooops sorry I just relised you might even mean decimal even then I screwed it up, should be 52 hex anyway. It still could be the point thing, I thought it was the MSB, but it may not be. This has thrown me a couple of times. [This message has been edited by Bryan Russell (edited 02-27-2000).] IP: Logged
Laika 801 Pilot	posted 02-28- 09:42 AM I´m a dumb ass in math, so should I use dec or hex ??? IP: Logged
charmstar Pilot	posted 02-28- 01:32 PM OK, this sounds like a great idea, but it doesn't work for me. I tried a whole slew of different numbers, like 00,08,20,28,50,52, and nothing worked. I _think_ the flag should be 20, because that is 00100000 in hex, right? And, that would correspond to a single sided regular poly which is primarily in the X direction, and has subnesting = 1, right? One reason that might be why this doesn't work is that my polys aren't coplanar. Basically I have: box -- cylinder -- box, where all parts are quite close to each other, like within about 6 inches or so, but aren't actually overlapping. The first box is longest in the X direction, the cyls are in the Y direction, and the second box is in the Z dir. If I orient all of these to be the same, will they be considered coplanar, even though they don't overlap? Actually, what is coplanar anyway? I assume that it means two objects share the same plane, but if the objects are 3 dimensional, how is coplanarness determined, since it is always possible to find some plane which intersects both objects? Also, everything looks great in OPS, it is only in SDOE that I have the rendering problems. Furthermore, I'm using a TNT card, if that matters, and also it seems like it doesn't matter how near/far away from the objects I am, they always have this problem. Any more ideas? charm IP: Logged
Spanky the Mad Dog Pilot	posted 02-28- 02:45 PM Spanky here... HAHA ok guys am i getting myself in for some crazy stuff? dec or hex ??? thats insane IP: Logged
Laika 801 Pilot	posted 02-28- 04:25 PM INSANE !?! 10 (dec) -> 00001010 10 (hex) -> 00010000 10 (dec) -> A (hex) IP: Logged
Laika 801 Pilot	posted 02-28- 04:49 PM I guess hexadecimal... IP: Logged
Bryan Russell Pilot	posted 02-28- 05:18 PM I think builder needs Decimal but if not then at least it would explain your problem! IP: Logged
Bryan Russell Pilot	posted 02-28- 05:26 PM charmstar: Co-planer means that the all of the vertices of the poly are one the same plane, i.e. the poly is perfectly flat. Why a non-planer poly is flicking in and out could actually be a OPS thing rather than a SDOE thing as OPS creates the face normals. non-planer polys probably still aren't a good thing but I maybe able to make them look better in the future by averaging a few normal calcs rather than the one I do now. Some advise for people using MAX and OPS at the moment is this... Forget about polys and just use triangles for the moment. Why? Well considering the current state of MAX2OBJ as far as polys goes, triangles are going to be less hassle, and you could spend hours dicking with polys. Sure there may be some FPS hit, but make the optimisation the last thing you do. If any decent polygon making tools to happen then you should be able to use them without re-textureing, re-shading or anything. IP: Logged
charmstar Pilot	posted 02-29- 11:17 PM Bryan- I'm almost certain the polys in question are coplanar, because they are all just slightly modified geometric shapes (i.e. a cube, with 3 sides deleted, a cylinder with 1 cap deleted, etc.) Also, the problem is completely consistent in SDOE regardless of distance. This isn't the flickering problem I'm talking about, but rather something different. Basically, I have a crossbrace, and just behind the crossbrace is a fuel tank. However, the fuel tank renders in SDOE as if it were in front of the crossbrace. In OPS, everything renders exactly as it ought to. I'm thinking that the subnesting might solve the problem, but I haven't been able to get it to work yet, and I don't know why :-( One piece of the puzzle I don't really understand is the Axis part of the polyflag bit field. The openplane doc says, "Axis (primary axis of surface normal. i.e. which component is longest) 0 poly_PrimaryX 1 poly_PrimaryY 2 poly_PrimaryZ " So, does this mean if the part is tilted at a 60 degree angle up from the xy plane, then it would be poly_primaryZ = 2 = 10? Also, am I correct in assuming that the frame of reference is the same as the one for the toplevel model, and not some arbitrary x' y' z' based off of the normal for a parent model or somesuch? cheers, charm IP: Logged
Bryan Russell Pilot	posted 03-01- 12:32 AM OPS will actually do that Primary Axis thing if you use the material naming thing as well. I guess the idea is to cull out the full calculations on normals that are going to be way off in the first place. The frame of reference should be world co-ordinates, but actually thinking about that, this would of course change if you rotated the model around in OPS, especially if the Face normal, and this primary normal as well weren't transformed with the LODs verts. Could explain a few things... But it sound's unlikely. I don't think all of this has to do with your problem, the sub-face thing is probably the only thing that's going to help. Either that or move the fuel tank just a little until it stops showing through. IP: Logged

All times are CT (US)	next newest topic \| next oldest topic
Administrative Options: Close Topic \| Archive/Move \| Delete Topic
	Hop to:

Contact Us | Fighter Squadron Information Center