New Celestia-1.4.0pre-FT1 (galaxies) for Testing

[Toti]

You don't mean negative numbers here to you?
I just proposed to (mis)use the sign as a flag for emissive/nonemissive drawn blobs - and be stripped off before handing over the value to OGL functions.

No, it's just that we are using additive blending which gives a nicer look and avoids the need to sort objects from back to front prior to render them.
Given this additive form, rendering another blob always increases brightness and never decreases it, no matter how dark it is.
There are possibly some ways to circunvent this without changing the blending function for bright blobs, being one of them to split the template into an emissive part and an absorptive one, but this could bring newer blending artifacts where the objects merge, etc.

Ok, thanks for the explanation.
But how would you avoid the problem by creating two parts for merging? There wouldn't be any depth information available. Rotating the result would look quite funny.

Yes, this is precisely the problem I alluded to: you can sort both objects according to the distance to their centers, but in the part they overlap/merge it will be quite messy.

[abramson]

No problems compiling from CVS. But the tar.gz file for FT1 will not go.
At first it crashed in celutil. Then I found out that if the Makefile and Makefile.in were deleted it started compiling. All those files were deleted from the archive. Now it crashes when trying to compile celengine. It gets stuck on execution.obj. C++ dosen't give much on the cmd line. syntax error and execution.obj unexpected were mentioned as the reasons for the crash.

Exactly the same happened to me. I also deleted the makefiles and the makefiles.in. I have MS Visual C++ Tolkit 2003 and MS Platform SDK (both free). I tried fiddling with engine.mak, to no avail.

Guillermo

[cartrite]

Guillermo wrote:[/quote]
Exactly the same happened to me. I also deleted the makefiles and the makefiles.in. I have MS Visual C++ Tolkit 2003 and MS Platform SDK (both free). I tried fiddling with engine.mak, to no avail.[quote]

I think the operative words here are (bothfree). The archive was developed on MS Visual C++ .Net (not free) which probally left some kind of markers or something that will not allow Visual C++ Toolkit 2003 and MS Platform SDK to work. Thats why Biil Gates is a billionare!
The markers are probally on the files preceeding execution.cpp which are dsoname, dsodb, dsooctree, etc. These are probally what makes FT1 FT1, so they have to stay.
OH WELL. Linux still works.

cartrite

[Brendan]

I fixed the problem. Near the $(INTDIR)\execution.obj \ line in engine.mak, there is a tab character there in the list of obj files. Remove that. I also removed the other whitespace I saw in the list.

[cartrite]

To Guillermo:

The answer is the engine.mak file in the celengine folder.

There are spaces in front of the 3 lines preceeding execution.obj.
You have to remove all spaces and hit tab to move them over (including execution.obg.
I think there were spaces (behind) one of the lines too.

I thought I read somewhere that you were supposed to use spaces instead of the tab key (c++ standard?) but all the other lines in that section of the file are tabbed over.

Anyhow it worked. And with the MS Visual C++ Toolkit 2003.
Sorry Bill Gates.

cartrite

[t00fri]

I fixed the problem. Near the $(INTDIR)\execution.obj \ line in engine.mak, there is a tab character there in the list of obj files. Remove that. I also removed the other whitespace I saw in the list.

Good. I tried to get rid of all of them, but since I am not using those *.mak's myself, apparently there were some left over.

Could someone zip the fixed mak's and send them to me by email.

Just for the FT1.1 release (tomorrow?)

Thanks

Bye Fridger

[t00fri]

Thanks Brendan, cartrite and Guillermo,

for sending the corrected engine.mak!

I now have found a simple way for both Linux people and Windows affectionados to coexist as to compiling the FT sources. All that had to be done in the source archive is the command 'make distclean' under Linux before packing the archive up.

This erases all Makefiles in all subdirectories such that there is no clash anymore with nmake.exe under Windows.
The problem was that the Windows nmake.exe stupidly also understands the filename 'makefile' , but NOT its content. ==> errors.

So the Windows fans just type makerelease.bat and you should be fine. I tried it with the batch version of VC++.net and it worked perfectly.

The Linux "compilados" need to type the usual statements one has to type for compiling CVS code.

So the bugfix FT1.1 version will be uploaded (very soon) precisely in this form.

Cheers,
Bye Fridger

[maxim]

Ok, thanks for the explanation.
But how would you avoid the problem by creating two parts for merging? There wouldn't be any depth information available. Rotating the result would look quite funny.

Yes, this is precisely the problem I alluded to: you can sort both objects according to the distance to their centers, but in the part they overlap/merge it will be quite messy.

Have you ever profiled the costs of depth sorting vs adaptive blending? Maybe LOD switching would to the job. How many galaxies are supposed to be simultaneuosly displayed at a size of maybe >1/10 of screen size - not more than two I'd bet. So a LOD mechanism may kick in, and switch the render functions for those ones. Shouldn't cause a major drop in framerate, and is independent of the total amount of galaxies.

Just a thought,

maxim

[t00fri]

How many galaxies are supposed to be simultaneuosly displayed at a size of maybe >1/10 of screen size - not more than two I'd bet.
...
maxim

Maxim,

if you take "screen size =screen height" then you lost that bet by far. Here are three of many examples. But the most striking is Stephan's Quintet, i.e 5 ~ equally large galaxies /VERY close/ together. In the lower two images, it even doesn't matter what you chose as screen size .

Bye Fridger

[selden]

I've tripped over another rendering bug in 1.4.0 cvs (and FT1): normal maps do nothing.

Here's Mare Orientale as seen with a 4K normal map and 16K VT using pre6:


Here it is using cvs/FT1:


*grump*

[t00fri]

I've tripped over another rendering bug in 1.4.0 cvs (and FT1): normal maps do nothing.

Oh NO...One has to go back in CVS to just before Chris' last commit including all of DrJoe's patches...and then add one patch after the other, checking each time...

Bye Fridger

[Boux]

Hi there!
First, thanks for the hard work
I have just installed the latest 1.4.0pre-FT1.
About the Control-V bug in windows, I have found a work-around, at least on this machine.
I have commented out the following line in celestia.cfg:
IgnoreGLExtensions [ "GL_ARB_vertex_program" ]
Now I am able to ctrl-v cycle from "basic" to "opengl 2" with no more crash.
Interestingly, the "Geforce FX" aka NV30 option is no longer available.
This may show a hint about the bug.

The disappearing Milky Way bug is still there though.

Config here is P4E @ 3.55Ghz with Geforce 6800 Ultra and 77.72 drivers (not the latest but very stable in all apps)

[t00fri]

Selden,

I am a bit confused.

I did a clearcut test with FT1 under LINUX-KDE: using for Mercury the white westgrid.jpg texture and Mercury's 8k dds normalmap that I did myself.

So you are only seeing the normalmap on top of "nothing"!

Here is the result: On top, the render path is Basic, hence no normal map effects visible. The lower image is what I see with all other render paths higher than multitexture, including OpenGL 20 that I use normally.

Bye Fridger

[t00fri]

Hi there!
First, thanks for the hard work
I have just installed the latest 1.4.0pre-FT1.
About the Control-V bug in windows, I have found a work-around, at least on this machine.
I have commented out the following line in celestia.cfg:
IgnoreGLExtensions [ "GL_ARB_vertex_program" ]
Now I am able to ctrl-v cycle from "basic" to "opengl 2" with no more crash.
Interestingly, the "Geforce FX" aka NV30 option is no longer available.
This may show a hint about the bug.

The disappearing Milky Way bug is still there though.

Config here is P4E @ 3.55Ghz with Geforce 6800 Ultra and 77.72 drivers (not the latest but very stable in all apps)

Hi Boux,

many thanks, that may indeed be an important hint!
I'll look into the code (and Chris /recent/ commits, most of all!

The other bugs are all fixed (including the lacking MilkyWay for Windows). A dot release FT1.1 is imminent

Bye Fridger

[dirkpitt]

Looks great. Thanks to Hank for taking the time to test out FT, and of course to Fridger & Toti the new deepsky code. I'm looking forward to FT1.1.

[selden]

Fridger,

I don't see any pictures in your response about normal textures.

However, I've been trying all sorts of combinations of options, and I can't get either of the CVS or FT1 versions to show shadows on the Moon. In the same directory tree and using the same Cel URL, only the pre6 executable shows shadows on the Moon in Render path OpenGL 2.0.

It now looks to me like this symptom is directly related to the crash problem. Both CVS and FT1 are starting in Render path Multitexture, which of course can't draw bumpmap shadows. Pre6 starts in Render Path "OpenGL vertex program", which does draw bumpmap shadows. Neither CVS nor FT1 list the Render path "OpenGL vertex program" when I cycle through the render paths. It looks like the bug is in the code related to vertex programs.

[t00fri]

Fridger,

I don't see any pictures in your response about normal textures.

However, I've been trying all sorts of combinations of options, and I can't get either of the CVS or FT1 versions to show shadows on the Moon. In the same directory tree and using the same Cel URL, only the pre6 executable shows shadows on the Moon in Render path OpenGL 2.0.

It now looks to me like this symptom is directly related to the crash problem. Both CVS and FT1 are starting in Render path Multitexture, which of course can't draw bumpmap shadows. Pre6 starts in Render Path "OpenGL vertex program", which does draw bumpmap shadows. Neither CVS nor FT1 list the Render path "OpenGL vertex program" when I cycle through the render paths. It looks like the bug is in the code related to vertex programs.

Selden,

Code: Select all

"Mercury" "Sol"
{

    Texture "westgrid.jpg"
    NormalMap "mercury-normal.dds"

....
}


sorry, the lower image in my response above just displays the distinct effect of my normal map. That's the usual way we used to test most clearly what the normal map does without being confused by the main texture (which is just a simple white globe: westgrid.jpg provided to Grant)

Hence any 3d effects (craters) you see are /directly/ due to the normal map! You find the respective part of solarsys.ssc above.

OK I shall go into that CTRL-V bug now. It is interesting that I don't get the CTRL-V bug and my normal map appears to work.

It now looks to me like this symptom is directly related to the crash problem. Both CVS and FT1 are starting in Render path Multitexture, which of course can't draw bumpmap shadows.

But not in the versions I compiled here! Neither for Windows nor for Linux. I always start in the last one, i.e usually OpenGL 2.0

It is clear that there must exist a configuration that avoids these bugs altogether...But which??

Bye Fridger

[Boux]

Weird...
Just checked with Mercury, Moon and Mars.
The normal maps do show up here (opengl2 path).
Could it be that some combination of hardware and drivers lead to differents patterns of behaviour?

[t00fri]

I have just checked the following:

After all, I told people to take the celestia-1.4.0pre6 Version that Chris had released last Nov 11, 2004, as a basis for our new FT1. However, we have built the FT1 version on top of the actual CVS version. So I checked whether any shader routine in the shaders dir might have been modified /after/ Nov 11, the release date of 1.4.0pre6!

Indeed there is one: ell_galaxy_arb.vp

from Chris' last commit August 15 2005, where he implemented DrJoe's patches and committed also some unfinished work on elliptical galaxies, for which the above shader was written.

However, that elliptical galaxy routine in galaxy.cpp is NOT activated and hence that shader is never used.

Any other shaders date from earlier than Oct 11 2004.

So I conclude, it's NOT due to more recent shaders code.

Bye Fridger

[selden]

Fridger,

Sorry I wasn't clear: I meant that there must be buggy changes in the C++ code of Celestia which is related to the vertex shaders. Among other things, it certainly is no longer properly detecting what functions are available in the card.

The vertex shader code that you are describing is the OpenGL code that gets loaded into the graphics card.