CVS bugs (stars, atmosphere,...)

[t00fri]

Description: An Extensible Extension Language
Version: 5.0.2
Requires:
Libs: -L${libdir} -llua -llualib
Cflags: -I${includedir}
...

ATTENTION, please! In the RPM archives that I downloaded the lua includes were NOT in that include dir.

Mine are in /usr/include/lua <==========

Bye Fridger

[phoenix]

Description: An Extensible Extension Language
Version: 5.0.2
Requires:
Libs: -L${libdir} -llua -llualib
Cflags: -I${includedir}
...

ATTENTION, please! In the RPM archives that I downloaded the lua includes were NOT in that include dir.

Mine are in /usr/include/lua <==========

Bye Fridger

yes, mine are in /usr/include/lua50

what about lua-config?

-I$(lua-config --include)
-L$(lua-config --libs)

should do the trick if lua-config is a standart-script provided by lua.

[cartrite]

If you were refering to the last line

Code: Select all

Cflags: -I${includedir}

That was a remnent from the lua.pc file I had from version 5.1.1 and it probally wasn't needed. Version 5.0.2 didn't have a luaconf.h so there were no cflags. When I tried to download the rpm the link was down so I built it from source. I guess that's why my prefix was /usr/local. A default that I didn't change.

[Paolo]

Sorry guys, all this is interesting, but....

I don't understand why there is this continue tendency in drifting the subject of the threads that wastes time and adds noise.

This is: ...\Forums\Developer talk\CVS bugs (stars, atmospheres, ...)


If something interesting related to the thread pops-up but is definitely OT, the discussion <b>HAS</b> to continue in another thread. Its a basic rule ! Please post a short initial message with a link to another thread and continue the discussion there.

Chris in another thread has already requested to follow this rule and Selden has already split the compressed normalmaps topic.

I don't want to sound harsh or be offensive against someone but don't go OT, if not we will fall again in the problems discussed some time ago related to the other forums.

Selden if you think that should be useful please post a sticky and then delete this message.

Thank you all.
Kind regards

[cartrite]

All the posts above that were posted by me today had to do with a change in configure.in in CVS on 9/10. When I tried to build CVS this morning the configure script failed and I thought it was a bug. If this was a drifting from the main topic I apologize.

[phoenix]

this thread is about cvs-bugs and that's what everyone is talking about here. no need to apologize...
the other threads where closed or split because of personal discussions.

I also have a problem with building current cvs with lua.
without "hacking" around the configure-script it won't find it automatically.

the bug must be in configure.in somewhere so this is actually cvs related and not OT

[Kolano]

I'm getting odd results from the OpenGL 2.0 render path.

Planets look like they are illuminated with a close spotlight. See the linked images below for samples. I think someone else had pointed this out, but I couldn't find that thread.

This one had no new atmosphere params (which I though might be my issue but its not)
http://kenkolano.com/celestia/mars2.jpg

This one has new atmosphere params
http://kenkolano.com/celestia/mars1.jpg

I'm using Pheonix's build "celestia_cvs_latest.zip 11-Sep-2006 20:20 1.8M" dropped on top of my old Celestia 1.4.1 install with a fairly full set of extras.

The issue arises when utilizing a 64k DDS VT normal map...

Modify "Earth" "Sol"
{
Texture "BMNG.ctx"
SpecularTexture "BMNG_spec.ctx"
#With the line below uncommented the image appears as in screenshots above.
# NormalMap "JNormal DDS.ctx"
NightMap "JNight DDS.ctx"

Atmosphere {
CloudMap "earth-clouds.ctx"
CloudSpeed 0
}
}

[Kolano]

Something in my "cassini_moons.ssc" file is causing a crash. The contents of the file are...

# Numbered moons of Saturn
"2004S1" "Sol/Saturn" # Between Mimas and Enceladus / Cassini-Huygens probe 2004
{
Texture "asteroid.jpg" # Default's Asteroid Texture
Mesh "asteroid.cms"
Radius 1.5

EllipticalOrbit
{
Period 1.01
SemiMajorAxis 194000
Eccentricity 0.000
Inclination 0.000 #
AscendingNode 000.0 #
ArgOfPericenter 00.0 # J2000.0
MeanAnomaly 000.0 #
}

Albedo 0.7
}

"2004S2" "Sol/Saturn" # Between Mimas and Enceladus / Cassini-Huygens probe 2004
{
Texture "asteroid.jpg" # Default's Asteroid Texture
Mesh "asteroid.cms"
Radius 2

EllipticalOrbit
{
Period 1.14
SemiMajorAxis 211000
Eccentricity 0.000
Inclination 0.000 #
AscendingNode 000.0 #
ArgOfPericenter 00.0 # J2000.0
MeanAnomaly 000.0 #
}

Albedo 0.7
}

"2004S3" "Sol/Saturn" # Cassini-Huygens probe 2004
{
Texture "asteroid.jpg" # Default's Asteroid Texture
Mesh "asteroid.cms"
Radius 2.25
InfoURL "http://www.jpl.nasa.gov/news/news.cfm?release=2004-222"

EllipticalOrbit
{
Period 0.7618
SemiMajorAxis 141000
Eccentricity 0.000
Inclination 0.000 #
AscendingNode 000.0 #
ArgOfPericenter 00.0 # J2000.0
MeanAnomaly 000.0 #
}

Albedo 0.7
}

---------
Crash Info:
AppName: celestia.exe AppVer: 1.4.1.0 ModName: unknown
ModVer: 0.0.0.0 Offset: 003d01d9

[t00fri]

Chris,

I still see the same red Earth ball as Christophe did before your fix

http://www.celestiaproject.net/forum/viewtopic ... c&start=16

once I switch on cloud shadows with my bigger size textures (tiles). Everything returns to normal, once I switch cloud shadows off.

Also with the default Earth textures things work fine.

Bye Fridger

[chris]

Chris,

I still see the same red Earth ball as Christophe did before your fix

http://www.celestiaproject.net/forum/viewtopic ... c&start=16

once I switch on cloud shadows with my bigger size textures (tiles). Everything returns to normal, once I switch cloud shadows off.

Also with the default Earth textures things work fine.

Can you post a link to your shaders.log?

--Chris

[t00fri]

Chris,

I still see the same red Earth ball as Christophe did before your fix

http://www.celestiaproject.net/forum/viewtopic ... c&start=16

once I switch on cloud shadows with my bigger size textures (tiles). Everything returns to normal, once I switch cloud shadows off.

Also with the default Earth textures things work fine.

Can you post a link to your shaders.log?

--Chris

Certainly:
======
http://www.celestiaproject.net/~t00fri/images/ ... haders.log

Actually, as soon a I switch one of my various texture tile overlays off, things work again. E.g. if I switch off the nightlight VT's.

Bye Fridger

[chris]

Certainly:
======
http://www.celestiaproject.net/~t00fri/images/ ... haders.log

Actually, as soon a I switch one of my various texture tile overlays off, things work again. E.g. if I switch off the nightlight VT's.

The shader generator produces a shader that uses too many interpolators. All the textures, plus the scattering term, tangent space vectors, etc. are just too much. Disabling night lights means that an interpolator isn't required for the night map coordinates, and that's just enough to allow the shader to fit within the hardware resource limits. I have an idea for a way to reduce the number of interpolators required for texture coordinates.

--Chris

[fsgregs]

I just tested out Cartrite's new Windows build of 1.5.0 and can confirm that the flare.jpg texture disappears when you reach a distance of about 3 au from a star.

Here are some screenshots (p/s - I am using a modification of Runar's sun texture):

[/URL][/img]

[img][img]http://img75.imageshack.us/img75/4874/flareinvisibleqh7.jpg[/img][/img]



Notice that the above image also has that annoying striped line effect in the star.


[img][img]http://img208.imageshack.us/img208/3005/flareinvisible3bu2.jpg[/img][/img]

No flare texture at all.

FYI

Frank

[Cham]

I have the same glare problem with my current version of Celestia (1.4.2 from Dirkpitt).

The stripped texture problem is very frequent with a model layered on top of a Celestia sphere (here, it's Runar texture on top of the sun). I've experienced this frequently with many addons.

[symaski62]

http://www.purebytes.de/stuff/celestia/ UPDATE 9/13/2006

[phoenix]

chris already explained this somewhere.
the black dots around stars result from the old atmosphere-code that is currently still used for stars

[dirkpitt]

I'm getting odd results from the OpenGL 2.0 render path.

Planets look like they are illuminated with a close spotlight. See the linked images below for samples. I think someone else had pointed this out, but I couldn't find that thread.

Here is the thread.

It is not a bug. It is caused by your use of a non-compressed DDS normal map, as you confirm in your post...

The issue arises when utilizing a 64k DDS VT normal map...

[chris]

I'm getting odd results from the OpenGL 2.0 render path.

Planets look like they are illuminated with a close spotlight. See the linked images below for samples. I think someone else had pointed this out, but I couldn't find that thread.

Here is the thread.

It is not a bug. It is caused by your use of a non-compressed DDS normal map, as you confirm in your post...

The issue arises when utilizing a 64k DDS VT normal map...

It is something that I'd like to fix though. It sounds like there are more DXT compressed normal maps out there than I'd thought, and I'd hate to break them all.

--Chris

[steffens]

It is something that I'd like to fix though. It sounds like there are more DXT compressed normal maps out there than I'd thought, and I'd hate to break them all.

What about my suggestion to simply use another file name extension for compressed normalmaps in DDS files, something like ".cnm" or ".dxt5nm"?

steffens

[chris]

It is something that I'd like to fix though. It sounds like there are more DXT compressed normal maps out there than I'd thought, and I'd hate to break them all.

What about my suggestion to simply use another file name extension for compressed normalmaps in DDS files, something like ".cnm" or ".dxt5nm"?

That's a very sensible idea . . . I think that might be the best solution.

--Chris