Problem Transparent/glass surface masking objects behind

[Spike Spiegel]

I'm having this problem where my transparent canopy material is masking certain things behind it. As you can see in the image, it's masking the Delta-Glider, but not the runway marker (or other surface buildings). It's also masking the pilot's transparent visor.

This model was created in 3DS Max 7. I used the max2msh129b plugin to import the Delta-Glider, then pulled the materials from the cockpit glass, pilot visor, and the hud glass. The pilot in my mesh is also (obviously) from the Delta-Glider. I then applied these same materials to my canopy and pilot's visor, then used the same max2msh plugin to export my model.

So, any ideas what's going on here? Most importantly, is there a way to fix it? I noticed that the Delta-Glider's glass does not cause this same effect, so there must be a way to correct it. Thanks in advance for all your help.

 

[Hielor]

I'm having this problem where my transparent canopy material is masking certain things behind it. As you can see in the image, it's masking the Delta-Glider, but not the runway marker (or other surface buildings). It's also masking the pilot's transparent visor.

This model was created in 3DS Max 7. I used the max2msh129b plugin to import the Delta-Glider, then pulled the materials from the cockpit glass, pilot visor, and the hud glass. The pilot in my mesh is also (obviously) from the Delta-Glider. I then applied these same materials to my canopy and pilot's visor, then used the same max2msh plugin to export my model.

So, any ideas what's going on here? Most importantly, is there a way to fix it? I noticed that the Delta-Glider's glass does not cause this same effect, so there must be a way to correct it. Thanks in advance for all your help.

In order for an object to appear behind a transparent polygon, it must be fully rendered before the transparent polygon. Within a vessel, you can control the polygon ordering, so you can ensure that the transparent bits are drawn last (so any part of your vessel will be visible through the windows).

However, there is no way to control the order in which vessels are rendered in the scenario, so you can't guarantee that all other vessels will be drawn before yours. It's a limitation of the rendering engine.

 

[Spike Spiegel]

Problem Solved - Thanks!

Hielor,

Thanks for your help, your advice allowed me to fix the problem. I've made 3D models before, but I'm totally new to putting them into a realtime game/sim environment.

I went into the .msh file and switched the order of the transparent objects, making sure that they were all at the end of the objects, and also that they were listed from innermost to outermost. Now the pilot's visor is visible again (before, it had been listed after the canopy).

I also tried applying the same logic to the scenario file, moving my ship to the end of the ship listing. As you can see in the picture, my ship's canopy no longer masks the Delta-Glider; the DG's cockpit glass now masks my ship however. I figure since my ship has a lot more glass, this effect is more likely to be noticed if my ship is in front of another. I'll keep it at the end of the other ships.

Again, thanks for the help!

 

[Hielor]

Hielor,

Thanks for your help, your advice allowed me to fix the problem. I've made 3D models before, but I'm totally new to putting them into a realtime game/sim environment.

I went into the .msh file and switched the order of the transparent objects, making sure that they were all at the end of the objects, and also that they were listed from innermost to outermost. Now the pilot's visor is visible again (before, it had been listed after the canopy).

I also tried applying the same logic to the scenario file, moving my ship to the end of the ship listing. As you can see in the picture, my ship's canopy no longer masks the Delta-Glider; the DG's cockpit glass now masks my ship however. I figure since my ship has a lot more glass, this effect is more likely to be noticed if my ship is in front of another. I'll keep it at the end of the other ships.

Again, thanks for the help!

Yup, that'll work, but if someone adds another vessel using the scenario editor it'll get added after yours.

 

[gattispilot]

mesh inside a vessel with glass windows

Not to steal the thread. But this seems similar.

I am reworking the Lost in Space Chariot to be Ummu. But I am adding a mesh of a passenger if a crew is present. But I have a problem. You can only see the person from the outside if the door/windows are open.

if it matters here is the code:

    SetMeshVisibilityMode (AddMesh (oapiLoadMeshGlobal ("chariotlite")), MESHVIS_ALWAYS); //Main ship mesh
SetMeshVisibilityMode (AddMesh (oapiLoadMeshGlobal ("CHARIOTEVA1A")), MESHVIS_NEVER);

if ((Crew.GetCrewTotalNumber()>0))SetMeshVisibilityMode( 1, MESHVIS_ALWAYS ); 
      else  SetMeshVisibilityMode( 1, MESHVIS_NEVER );

And it would continue with meshs of 6 crew.

 

[Spike Spiegel]

Open the .msh file in a plain text editor like Notepad. I don't know what method you used to convert your model to the .msh format, but with the plugin I used, the object names are kept, and they appear as LABEL lines in the .msh file. For example, I have "LABEL canopy", followed by all the data related to that object. As I'm sure you can guess, this means that giving your objects meaningful names is a big help.

You should then be able to select everything from the start of that LABEL until the last line before the next LABEL, cut that (Ctrl+X), then paste it in wherever you want, such as near or at the end of the other objects. I made sure to paste it in before the MATERIALS section however. I assumed this was the next "section" of code, beyond the object definitions. I don't know what horrible demons will be unleashed upon your mesh if you paste an object after the MATERIALS section.

So that's what worked for my problem, and hopefully it works for you as well. I didn't know of a way to change the order from within 3DS Max, so I went with the text editor.

 

[Ursus]

Gattispilot... have you tried adding the (invisible) passenger meshes BEFORE you add the Chariot mesh (then setting them visible as necessary)?

It may seem counter-intuitive, but I'd think it would cause the passenger meshes to be rendered before the vehicle (lower mesh index within vehicle's set of meshes means that Orbiter renders it first), thus having the same effect as the above bug fixes.

Example:

SetMeshVisibilityMode (AddMesh (oapiLoadMeshGlobal ("CHARIOTEVA1A")), MESHVIS_NEVER);
SetMeshVisibilityMode (AddMesh (oapiLoadMeshGlobal ("CHARIOTEVA2A")), MESHVIS_NEVER);
SetMeshVisibilityMode (AddMesh (oapiLoadMeshGlobal ("CHARIOTEVA3A")), MESHVIS_NEVER);
SetMeshVisibilityMode (AddMesh (oapiLoadMeshGlobal ("CHARIOTEVA4A")), MESHVIS_NEVER);
SetMeshVisibilityMode (AddMesh (oapiLoadMeshGlobal ("CHARIOTEVA5A")), MESHVIS_NEVER);
SetMeshVisibilityMode (AddMesh (oapiLoadMeshGlobal ("CHARIOTEVA6A")), MESHVIS_NEVER);

SetMeshVisibilityMode (AddMesh (oapiLoadMeshGlobal ("chariotlite")), MESHVIS_ALWAYS); //Main ship mesh

int count;
for (count = 0; count < 6; count++)
{
      if ((Crew.GetCrewTotalNumber()>count))SetMeshVisibilityMode( count, MESHVIS_ALWAYS ); 
            else  SetMeshVisibilityMode( count, MESHVIS_NEVER );
}

 

[gattispilot]

Thanks. That fixed that. Of course I needed to go and adjust the animations.

 

[gattispilot]

not sure this is fixable or not.

You can see the Ummu guy thru the front glass. but if I change the angle now he is gone. Is it because it is going thru 2 windows?

 

[martins]

With transparent surfaces, the simple z-buffer algorithm employed by directx (and probably most other render engines) doesn't work any more, since the z-buffer entry doesn't know if it was generated by a solid or semi-transparent surface. So any object rendering to the same pixel at a greater distance after the glass pane was rendered will be suppressed, i.e. become invisible.

The only way around this is to resort to old-fashioned depth-sorting. Render your objects from furthest to closest. In your case, render the interior of the cabin first, then render all the glass panes from innermost to outermost.

Of course, this can soon become a bit tedious, since different camera angles may require a change in the render sequence. For example, if the driver was semitransparent himself, you would first have to render the far part of the vessel, then the driver, then the near part. If the camera moves to the other side, the render sequence reverses. Or if the camera is inside the cabin, the render sequence for the glass panes would change from outermost to innermost.

 

[gattispilot]

The vessel has only one mesh. I guess the other solution is to remove the glass.

 

[Hielor]

As I already pointed out in this thread, and is also pointed out in the manual--if you have transparent bits of your mesh, they need be the last mesh groups in the .msh file.

 

[Ursus]

The MMu is standing outside the vehicle, on the other side, right?

I'd say that just removing the interior surface of the glass would be the best work-around. You'd still have the shiny surface when viewed from the outside, but you wouldn't have to worry about whether the far or near pane of glass was rendered first.

Or, come to think of it, you could make the interior surface of the glass a separate mesh group (actually, separate mesh groups, since you have animated parts) from the exterior and make sure it (they) comes before the exterior surface in the mesh file. Remember that mesh surfaces are one-sided. The only time the inside visible surface would be closer than the outside visible surface would be when the door is open and the inside surface of the door becomes the "outside" surface. (It looks like the window in the door is probably symmetrical. Flip the window around instantaneously at a certain point during the door opening animation?)

It looks like it should be a workable puzzle.

Just getting rid of the interior surface of the glass would be easier, though.

 

[gattispilot]

right. So IF I make a interior mesh remove the glass
The glass material is last in the mesh.

The MMu is standing outside the vehicle, on the other side, right?

I'd say that just removing the interior surface of the glass would be the best work-around. You'd still have the shiny surface when viewed from the outside, but you wouldn't have to worry about whether the far or near pane of glass was rendered first.

Or, come to think of it, you could make the interior surface of the glass a separate mesh group (actually, separate mesh groups, since you have animated parts) from the exterior and make sure it (they) comes before the exterior surface in the mesh file. Remember that mesh surfaces are one-sided. The only time the inside visible surface would be closer than the outside visible surface would be when the door is open and the inside surface of the door becomes the "outside" surface. (It looks like the window in the door is probably symmetrical. Flip the window around instantaneously at a certain point during the door opening animation?)

It looks like it should be a workable puzzle.

Just getting rid of the interior surface of the glass would be easier, though.

 

[DarkWanderer]

With transparent surfaces, the simple z-buffer algorithm employed by directx (and probably most other render engines) doesn't work any more, since the z-buffer entry doesn't know if it was generated by a solid or semi-transparent surface. So any object rendering to the same pixel at a greater distance after the glass pane was rendered will be suppressed, i.e. become invisible.

Well, these problems can be avoided by forming a single index buffer for transparent objects and passing it to the renderer in one call. Z-buffer should work well then.

gattispilot, try breaking the glass into separate groups - e.g. front glass - one group, left ones - another and so on. If Orbiter uses depth sorting - this may help with the last issue.

 

[gattispilot]

Ok so I would have a main mesh for cockpit and external and then make seperate meshes for Always of the front window,...

Well, these problems can be avoided by forming a single index buffer for transparent objects and passing it to the renderer in one call. Z-buffer should work well then.

gattispilot, try breaking the glass into separate groups - e.g. front glass - one group, left ones - another and so on. If Orbiter uses depth sorting - this may help with the last issue.

 

[DarkWanderer]

Yeah. Try both - with groups and with separate meshes. May work.

 

[fort]

Somewhat off topic.

I forgot which values could be modified at the end of a mesh in the "material" part to render them transparent.

From this example, by example.

MATERIAL -- default --
0.878 0.878 0.878 1.000
0.878 0.878 0.878 1.000
1.000 1.000 1.000 1.000
0 0 0 1
MATERIAL material01
0.984 0.984 0.984 1.000
0.984 0.984 0.984 1.000
1.000 1.000 1.000 1.000
0 0 0 1

By advances, thank you, if someone has a response.

fort

 

[Hielor]

Somewhat off topic.

I forgot which values could be modified at the end of a mesh in the "material" part to render them transparent.

From this example, by example.

MATERIAL -- default --
0.878 0.878 0.878 1.000
0.878 0.878 0.878 1.000
1.000 1.000 1.000 1.000
0 0 0 1
MATERIAL material01
0.984 0.984 0.984 1.000
0.984 0.984 0.984 1.000
1.000 1.000 1.000 1.000
0 0 0 1

By advances, thank you, if someone has a response.

fort

Read the API Guide in the SDK docs.

 

[fort]

Yes, I know well, I read it. ..il there has a certain time...but I counted today on the memory. ..of someone else...

Isn't the laziness no more a virtue ?

---------- Post added at 09:27 PM ---------- Previous post was at 09:23 PM ----------

Yes, I know well, I read it. ..il there has a certain time...but I counted today on the memory. ..of someone else...

Isn't the laziness no more a virtue ?

Yes TCR 500 : the last number (alpha). I've play with it before my post but without success. I'll try again.

But thank you Hielor and TCR.

fort