cmodview: 3D mesh file utility for Celestia

[Fenerit]

The undelying idea is no bad at all: to have some sort of "scrapbook" in which to test new features before the big step is really good. Perhaps Fresnel lights will be tested here?

[duds26]

Cool, is it self shadowing or are the parts casting shadows on each other?

[Hungry4info]

And furthermore, will these shadows evolve as the lighting source changes?

[Fenerit]

And furthermore, will these shadows evolve as the lighting source changes?

I'm afraid that the reply will be YES!

[DOJOMO]

Thanks for this great utility.
I have two matters that I would be grateful for some help. Apologies if the questions have already been raised.

1. I dont get shadows cast. Possibly my old graphics card which supports only OpenGL1.4 is the cause. The menu option for OpenGL2.0 is greyed out. Is this the case?

2. I have seen that others have reported that jpg textures don't work. I have found the same although png, bmp and dds work fine. However if the jpeg textutes are converted to png and put in the same texture folder then they show up in cmod view Material Editor and can be selected. They are applied with the correct coordinates carried over from the jpeg texturing. Is this again to do with my antiquated computer or is this intended?

David

[Fenerit]

Shadows casting is experimental for now; for what I've understood, Chris do use the Cmodview as workplace, they aren't inserted into Celestia yet. Then they will requires Celestia's version beyond 1.6.1 and should be independent from texture's format.

EDIT LATER

The available Cmodview's versions doesn't have shadows yet.

[Fenerit]

1. I dont get shadows cast. Possibly my old graphics card which supports only OpenGL1.4 is the cause. The menu option for OpenGL2.0 is greyed out. Is this the case?

Forgot my previous post; set apart the shadows, the menu option is greyed out just because you do not have OpenGL 2.0.

[Hungry4info]

Any idea what version of Celestia to expect to see this in?
(and, on that same stroke, what about the improved ring shading?)

[chris]

To answer a few of the recent questions:

- The uploaded binary of cmodview doesn't have shadow support. I'll upload a new one over the weekend. I'm very interested in getting feedback on the performance and appearance of shadows with various graphics cards.

- Shadows (and improved ring shading) will be in the version of Celestia after 1.6.1

- Shadows will require OpenGL 2.0. Without shaders, there's not enough flexibility to get shaders looking really good.

--Chris

[chris]

I uploaded a new version of cmodview for Windows that can display shadows on systems with OpenGL 2.0. There are some hardcoded parameters that control the shadow quality, such as the shadow map size. Right now, the shadow maps are 1024x1024; 2048x2048 shadow maps use more memory (16MB instead of 4MB), but produce much better looking shadows. I'll soon add the capability to change the shadow map size as well as the number of shadow map samples used.

The link is the same as before:
http://www.celestiaproject.net/~claurel/celest ... -win32.zip

--Chris

[abramson]

I'm very interested in getting feedback on the performance and appearance of shadows with various graphics cards.

Shadows appear and perform well in my GeForce 7300 LE (256MB dedicated memory), on a Core2 Duo E6550 running W7U-32b.

Guillermo

[NorthOfPolaris]

This is cmod's view representation of the underside of body.cmod from JRB_Freedom7/models in my extras folder.

The only setting changed from the default values in cmodview is in the render style menu where I have checked the shadows option.

My system consists of an ASUS board with an Intel core2duo at 2.2 GHz and GEForce 8800 GT video card with the latest NVidia drivers.

I could post more view with the settings changed to what you would like.

Serge

[Fenerit]

Hi! My test with Geforce 6100 256Mb shared. Here the shadow of the big antenna cast on the Cassini's body and all seem regular:


But if I turn the model on itself and then I turn the light around it, the big antenna cast the shadow as well( )


Furthermore, below, with the Galileo model, I get a "venetian blind" effect that seem more marked when the meshes are as low facets as possible, since with some of the Cassini's meshes that effect is no visible.

[chris]

Hi! My test with Geforce 6100 256Mb shared. Here the shadow of the big antenna cast on the Cassini's body and all seem regular:

The extra shadows are caused by invisible geometry in the Cassini model. The Cassini model should be fixed, as this extra geometry is no longer needed to keep the model centered in Celestia 1.6.0. The shadow code should also be modified so that invisible parts of models don't cast shadows.

But if I turn the model on itself and then I turn the light around it, the big antenna cast the shadow as well( )


Furthermore, below, with the Galileo model, I get a "venetian blind" effect that seem more marked when the meshes are as low facets as possible, since with some of the Cassini's meshes that effect is no visible.

These artifacts are the result of limited depth buffer precision. Cassini's antenna is a worst case for this sort of problem. I'm testing alternate shadow algorithms that should have less "acne".

--Chris

[Chuft-Captain]

The shadow code should also be modified so that invisible parts of models don't cast shadows.
--Chris

Good to hear this as that was a question I was going to ask -- "whether transparent meshes would cast shadows". Unfortunately, I don't have OGL2 at present so I'm sorry but I cannot contribute to testing these planned new features (but I can still chip in with the occasional suggestion. )

The other thing to remember when coding for the transparent mesh case, is that I believe that a common workaround for depth sorting problems associated with transparent meshes is to give the transparent mesh an opacity of 0.01 so that it is not truly transparent (I'm pretty sure that Selden and/or Runar use this technique), so maybe you need to set a threshold for casting of shadows when transparency is involved. (This could be set to some low value of opacity such as 0.01 or 0.02 in celestia.cfg)

The other Q that occurred to me is -- what sort of shadow would a 50% transparent mesh cast?
... also : EDIT: what effect might an intervening translucent mesh have on the shadows cast by another opaque mesh on a third mesh? eg. A mast casting a shadow through a translucent window onto another mesh (not to mention the appearance of the shadow on the translucent mesh).
Just some things to think about, but I suspect that shadow casting may be complicated enough already without considering all these scenarios (unless of course you can generalize the code enough to handle most or all scenarios).

CC

[NorthOfPolaris]

Chris,

Look at how nicely these J-antennas cast their shadows on the multi-faceted surface of the vostok1.cmod file.

I was able to reproduce what appears to be diffraction rings apparent in Fenerit's example. These artefacts appear on all .3ds files viewed with cmodview.

For computer equipment, please see my previous posting.



Serge

[Chuft-Captain]

Further to the questions above, one more question for you Chris...

How will you be handling shadows cast onto colored and/or textured meshes. Will the part of the texture covered by a shadow be darkened but retain it's hue, or will cast shadows simply replace the texture/color with a plain gray hue?
In the Vostok1 image above, I cannot tell whether parts of the green mesh covered by a shadow are a darker shade of green, or just a dark gray, so I'm not sure which option you're using at present.

Obviously, the more complicated first option will give a more realistic result, but will there be a significant cost to calculate new RGB values based on the current color of each shaded pixel ???

CC

EDIT: A closer (eyedropper) inspection of the Vostok1 image above does suggest that you are indeed preserving the existing hues in shaded areas.
I don't know whether in this model that is a texture or a color, but I assume that what works for colored meshes will also work for textured meshes. ??

[Fenerit]

I don't know whether in this model that is a texture or a color, but I assume that what works for colored meshes will also work for textured meshes. ??

Sure! Your Colony will have shadow zones.

[chris]

Further to the questions above, one more question for you Chris...

How will you be handling shadows cast onto colored and/or textured meshes. Will the part of the texture covered by a shadow be darkened but retain it's hue, or will cast shadows simply replace the texture/color with a plain gray hue?
In the Vostok1 image above, I cannot tell whether parts of the green mesh covered by a shadow are a darker shade of green, or just a dark gray, so I'm not sure which option you're using at present.

Obviously, the more complicated first option will give a more realistic result, but will there be a significant cost to calculate new RGB values based on the current color of each shaded pixel ???

The color of the shadowed geometry is retained, even when the source of that color is a texture map. There's no extra performance cost to calculate the RGB values instead of gray tone. Of course, when there's no source of light other than direct sunlight (i.e. no ambient light and no planetshine), the shadowed areas will be completely black.

--Chris

[Chuft-Captain]

Sure! Your Colony will have shadow zones.

Actually, I'm expecting it will have surprisingly few shadows cast on it's geometry (as it always points directly at the Sun). In a sense this is a shame for this model, as I think shadow casting if done well will significantly enhance the realism of Celestia's spacecraft and other non-terrestrial objects, however I am more concerned with making this colony concept realistic, rather than just looking pretty.
If the colony was positioned at an angle to the sun, then yes, I would expect to see many moving shadows cast on the colony from other parts of it's geometry, but in that orientation the colony concept is no longer believable as (in real life) it's axis would be required to point at the sun at all times in order for sunlight to be properly introduced into the interior by the mirrors.

The color of the shadowed geometry is retained, even when the source of that color is a texture map. There's no extra performance cost to calculate the RGB values instead of gray tone. Of course, when there's no source of light other than direct sunlight (i.e. no ambient light and no planetshine), the shadowed areas will be completely black.

--Chris

That's good news!
Perhaps with the introduction of this new feature we will need a corresponding change in terminology.
I suggest:

"Shadowed areas" for areas of geometry shaded by other geometry;
"Unlit areas" for geometry which is hidden from the Sun (and other light sources).

I think it is "unlit" areas you are referring to when you talk about it being completely black.

"Shadowed" areas I imagine will in most cases retain some degree of their original color. Exactly how much, may depend on the nature (ie. opacity) of the geometry which is casting the shadow. -- Chris, did you see my earlier post regarding the nature of shadows cast by (or through) semi-transparent meshes? (You made no comments in your reply regarding those issues.)

CC