Celestia Forums

I am getting depth sorting problems on my system again. I realize it probably has to do with the cmod shell around the star and probably due to the fact that I have an ATI. However, this is a pretty new problem. I cannot pinpoint the exact build that it started happening in. The two shots below show the problem not occuring in a 1.4 build and occurring in a 1.5 (Dec 11 build). As you can see in the second shot the white dwarf is in front of the orange star but it's accretion disk is behind the orange star, which is not the case in the previous builds. The disk should be in front of the "shell". If I remove the shell, the disk DOES show in front of the star, so it is definitely a result of a current change in the star code.

For a while there I was experiencing bleed through of the larger star through the "shell" cmod, but the depth sorting was fine. I need the shell to show the Roche lobe fill...

These shots were taken from roughly the same vantage point in both builds.

I suspect that if you can find a way to avoid using a translucent model, they'll be drawn correctly.

Celestia does still have problems with translucent textures. They're somewhat improved if you specify the material in the model to be translucent with an opacity of 0.99 instead of applying a translucent surface texture image to a model with a material opacity of 1.0.

There also are circumstances when models consisting of translucent materials (with no surface textures at all) are drawn behind opaque meshes they actually are in front of.
I'm seeing this effect in my model of the Hale telescope: its light paths are shown by using materials that are both translucent and emissive.

It also helps to experiment with the order the objects are loaded into Celestia memory. For example, it draws the first loaded object first and the last one last.

So, if the accretion disk is defined later in the ssc / stc order than the star, it will always be drawn behind it.

- rthorvald

PS: 98% translucent material works, 99% seems to be too little, at least in Pre3, which is the last i have tested with.

rthorvald wrote:It also helps to experiment with the order the objects are loaded into Celestia memory. For example, it draws the first loaded object first and the last one last.

Not true--the drawing order is determined in a back-to-front sort by objects most distant point (in z) from the viewer.

So, if the accretion disk is defined later in the ssc / stc order than the star, it will always be drawn behind it.

- rthorvald

PS: 98% translucent material works, 99% seems to be too little, at least in Pre3, which is the last i have tested with.

I remember this from before, but it still seems very odd to me. I think it has something to do with how your modeling software exports materials, because Celestia should be treating any value less than 100% as translucent (well, actually any value less than 254/255).

--Chris

selden wrote:Celestia does still have problems with translucent textures. They're somewhat improved if you specify the material in the model to be translucent with an opacity of 0.99 instead of applying a translucent surface texture image to a model with a material opacity of 1.0.

I think that Selden is right and setting the opacity to a value lower than 1.0 will fix the problem.

There also are circumstances when models consisting of translucent materials (with no surface textures at all) are drawn behind opaque meshes they actually are in front of.
I'm seeing this effect in my model of the Hale telescope: its light paths are shown by using materials that are both translucent and emissive.

Hmm . . . I thought I'd fixed model rendering so that all the translucent parts were rendered after opaque parts.

--Chris

Chris,

If you carefully watch the last few seconds of the video I made of the Hale telescope model (The Addon isn't finished yet, sorry), you'll see some portions of the light path appearing and disappearing -- especially the part that's directly in front of the primary mirror. It seems to change color between yellowish when the translucent, emissive light is correctly drawn in front of the mirror and silver when it is not.

Of course, it's a complex system with many models involved.

The video can be seen at http://www.youtube.com/watch?v=1d68rm53q8o

I'm also experiencing some odd behavior of transparent parts, but ONLY after I converted the model to CMOD, using the CMOD tool. The 3ds model doesn't have any depth sorting problem in Celestia, with its semi-transparent parts. The CMOD version do have depth sorting problems.

... and there are those smoothing problems with the CMOD tool, which ElChristou can describe in details...

Cham wrote:I'm also experiencing some odd behavior of transparent parts, but ONLY after I converted the model to CMOD, using the CMOD tool. The 3ds problem doesn't have any depth sorting problem in Celestia, with its semi-transparent parts. The CMOD version do have depth sorting problems.

... and there are those smoothing problems with the CMOD tool, which ElChristou can describe in details...

I'd love to look at these bugs, but I need help. Please, go to the SourceForge bug tracker to file bug reports about issues that annoy. Sign up for a SourceForge user ID if you don't have one. Have a quick look through the list of open issues to see if something has already been reported. Include links to files and whatever steps are necessary to reproduce the problems. Bugs that are reported on the tracker get fixed; bugs reported in forum threads tend to get forgotten.

--Chris

Cham wrote:I'm also experiencing some odd behavior of transparent parts, but ONLY after I converted the model to CMOD, using the CMOD tool. The 3ds model doesn't have any depth sorting problem in Celestia, with its semi-transparent parts. The CMOD version do have depth sorting problems.

... and there are those smoothing problems with the CMOD tool, which ElChristou can describe in details...

That is interesting. If I have a chance I'll try my models as 3ds instead of cmod tonight.

chris wrote:

rthorvald wrote:It also helps to experiment with the order the objects are loaded into Celestia memory. For example, it draws the first loaded object first and the last one last.

Not true--the drawing order is determined in a back-to-front sort by objects most distant point (in z) from the viewer.

Hm. Where did i get that from... An older version, perhaps.

Well, nice to have that one cleared up.

- rthorvald

The "first to last" drawing is what happens with DSC Nebula Mesh objects. It would be nice if someday they were depth sorted.

My problem is definitely directly related to the (stc) stars under the cmods. I changed the size of the star inside the Roche lobe to 1 km and the depth sorting problem disappeared. I noticed that the white dwarf inside the disk is exhibiting the same issues. I guess I will have to create this model without actual star sizes for now... I can make them both 1 km and just have shells "imitating" their true radii for now, but I would like to see the problem eventually go away...

I didn't have a chance to try the 3ds' instead of cmods....

buggs_moran wrote:
...

I noticed that the white dwarf inside the disk is exhibiting the same issues.

...

Sorry if I'm in wrong comprehension, this is mean that the white dwarf is translucent? If so, look at the texture and made it 24 bit instead of 32 bit.

Fenerit wrote:

buggs_moran wrote:
...

I noticed that the white dwarf inside the disk is exhibiting the same issues.

...

Sorry if I'm in wrong comprehension, this is mean that the white dwarf is translucent? If so, look at the texture and made it 24 bit instead of 32 bit.

No. The star's disk shows through the gas that surrounds it. It looks like the star is actually in front of things that it is behind...

Understood. You could make 24 bit the ring, but will lost the translucent's gaps within.

selden wrote:The "first to last" drawing is what happens with DSC Nebula Mesh objects. It would be nice if someday they were depth sorted.

Yes, this would be nice--it's worth iadding it to the feature tracker on SourceForge.

--Chris

done.