Posted: 12.07.2006, 19:05
Very impressive, Chris! What a great feature. Jeamchris wrote:Another screenshot, this time using Don Edwards's 4k cloud texture
Real-time 3D visualization of space
https://celestiaproject.space/forum/
https://celestiaproject.space/forum/viewtopic.php?f=4&t=9794
Very impressive, Chris! What a great feature. Jeamchris wrote:Another screenshot, this time using Don Edwards's 4k cloud texture
Yeah, realize that. I knew that you wouldn't want to force people to upgrade. (When I said "forces me to upgrade", what I really meant was "motivates me to upgrade".chris wrote:Celestia will continue to support older graphics hardware, but a lot of the new rendering methods are only practical on OpenGL 2.0/DX9 capable hardware.Chuft-Captain wrote:Firstly I'd just like to say this work and your other work on improved rendering looks absolutely awesome Chris. Unfortunately I won't be able to benefit from any of this as I don't have OpenGL 2.0 graphics.
This could well be the release that finally forces me to upgrade my desktop memory and graphics (perhaps to a Nvidia card).
chris wrote:Just one question about the following list of priorities. I see that depth-sorting issues is not on the list. Have you given up on that Chris?, or just forgot to mention it? Or have you fixed it already? (***typed with a hopeful tone*** )
I should have put that on the list too. I recently fixed one depth sorting bug that Selden had alerted me about. But, if you're talking about depth sorting of transparent objects, that's a ways off.
selden wrote:Unfortunately, it looks like I was mistaken about the 5nnn series of cards. The cloud shadows don't appear when using an Nvidia FX 5200 card. Apparently the v3 shaders are needed (GF 6nnn or better). 5nnn cards have v2 shaders
Sorry.
selden wrote:I assume you're referring to my brief mistaken comment about 5nnn cards. I was wrong. I'd forgotten to switch to the OpenGL 2.0 render path.
Performance isn't all that great, though.
On a 2.4GHz P4 with an FX5200, I'm only getting about 6fps.
selden wrote:This speed is with the standard Celestria v1.4.1 final distribution. The only changes are that
a. I'm running a copy of the Celestia executable compiled this morning from the code in the SourceForge CVS repository and that
b. I raised the cloudheight from 7 to 70 so the shadows would be more visible.
t00fri wrote:Chris,
beyond what I wrote in the dev list, there is another gridlike artefact of the spec background visible now (it was there before, too, but MUCH weaker):
t00fri wrote:Chris,
the clouds turning black (=> shadows) I was referring to in the dev list, arise if the "I" key is pushed. The white clouds are turned off, but their black shadows REMAIN . So it is a bug.
Code: Select all
Target: GeForceFX 5200 Ultra (NV34) :: Unified Compiler: v81.95
Cycles: 28 :: # R Registers: 4
Pixel throughput (assuming 1 cycle texture lookup) 28.57 MP/s
Target: GeForceFX 5900 Ultra (NV35) :: Unified Compiler: v81.95
Cycles: 20 :: # R Registers: 4
Pixel throughput (assuming 1 cycle texture lookup) 90.00 MP/s
Target: GeForce 6600 GT (NV43-GT) :: Unified Compiler: v81.95
Cycles: 11.00 :: R Regs Used: 3 :: R Regs Max Index (0 based): 2
Pixel throughput (assuming 1 cycle texture lookup) 363.64 MP/s
Target: GeForce 6800 GT (NV40-GT) :: Unified Compiler: v81.95
Cycles: 11.00 :: R Regs Used: 3 :: R Regs Max Index (0 based): 2
Pixel throughput (assuming 1 cycle texture lookup) 509.09 MP/s
Target: GeForce 7800 GT (G70) :: Unified Compiler: v81.95
Cycles: 9.00 :: R Regs Used: 3 :: R Regs Max Index (0 based): 2
Pixel throughput (assuming 1 cycle texture lookup) 1.07 GP/s
Code: Select all
uniform sampler2D diffTex;
uniform sampler2D normTex;
uniform sampler2D specTex;
varying vec2 diffTexCoord;
varying vec2 normTexCoord;
varying vec2 specTexCoord;
uniform vec3 ambientColor;
vec4 diff = vec4(ambientColor, 1.0);
varying vec3 eyeDir;
vec4 spec = vec4(0.0);
uniform float shininess;
varying vec3 lightDir0;
uniform vec3 lightcolor0;
uniform vec3 lightspecColor0;
void main(void)
{
vec4 color;
vec3 n = texture2D(normTex, normTexCoord.st).xyz * 2.0 - vec3(1.0, 1.0, 1.0);
float l;
vec3 eyeDirN = normalize(eyeDir);
vec3 hv;
float nDotHV;
l = max(0.0, dot(lightDir0, n)) * clamp(lightDir0.z * 8.0, 0.0, 1.0);
diff.rgb += l * lightcolor0;
hv = normalize(eyeDir + lightDir0);
nDotHV = max(0.0, dot(n, hv));
spec.rgb += l * pow(nDotHV, shininess) * lightspecColor0;
color = texture2D(diffTex, diffTexCoord.st);
gl_FragColor = color * diff + texture2D(specTex, specTexCoord.st) * spec;
}
Code: Select all
MOVR R0.xyz, f[TEX4];
ADDR R0.xyz, f[TEX3], R0;
DP3R R0.w, R0, R0;
RSQR R0.w, R0.w;
MULR R2.xyz, R0.w, R0;
TEX R1.xyz, f[TEX1], TEX0, 2D;
TEX R0, f[TEX2], TEX2, 2D;
MADR R1.xyz, R1, {2, -1}.x, {2, -1}.y;
DP3R R1.w, R1, R2;
MAXR R1.w, R1, {0}.x;
DP3R R1.x, f[TEX4], R1;
MAXR R1.y, R1.x, {0}.x;
POWR R1.w, R1.w, shininess.x;
MULR_SAT R1.x, f[TEX4].z, {8};
MULR R2.x, R1.y, R1;
MULR R1.x, R2, R1.w;
MULR R1.xyz, R1.x, lightspecColor0;
MOVR R1.w, {0}.x;
MULR R0, R0, R1;
MULR R1.xyz, R2.x, lightcolor0;
ADDR R2.xyz, R1, ambientColor;
MOVR R2.w, {1}.x;
TEX R1, f[TEX0], TEX1, 2D;
MADR o[COLR], R1, R2, R0;
END
It's a fundamental limitation of all currently shipping graphics hardware. In order for translucent objects to be rendered correctly, the triangles must be sorted so that the ones furthest from the viewer are rendered first. You can do the sorting on the CPU, but for a moderately detailed model this will be very slow. There are no practical workarounds that completely solve the problem. Only partial fixes exist.Chuft-Captain wrote:I'm happy to wait for as long as it takes if it's still high on your list of priorities. (Actually I've no choice in the matter as I'm not in a position to fix these bugs myself )chris wrote:I should have put that on the list too. I recently fixed one depth sorting bug that Selden had alerted me about. But, if you're talking about depth sorting of transparent objects, that's a ways off.
JOOI: What's the technical hurdle that makes the transparent depth-sorting more difficult to fix than Selden's bug?
Chuft-Captain wrote:Secondly, to which category do the problems I reported to you earlier in the year belong to? (Do you remember those?)
Do you think those problems will be resolved by the bug-fix you mention above, or are they in the category of transparent object depth sorting bugs?
Chuft-Captain wrote:BTW. Do you have any rough gut feeling for the likely "performance hit" of solving the DS problems as compared to the performance hit of the rendering improvements in your recent threads? Is it likely to be more or less of a performance drag than these other improvements?
Chuft-Captain wrote:PS. I apologise for harping on about DS issues when you've done all this great stuff on improving other aspects of the rendering, but just interested in progress on DS bugs as they cause a few serious problems as you know.
Personally, my approach (to software development in general) would be to give a higher priority to bugs such as the DS ones, which actually "break" the correct rendering of objects, versus quality improvements of things which aren't actually broken, which I would give a slightly lower priority to. (Of course I'm not doing any coding, but this is just my un-educated opinion from the point of view of the perceived overall quality of the software).
Of course, this opinion does not take into account the specific levels of difficulty and risk associated with these fixes, which I'm certainly not in a position to judge. Not to mention the fact that what you are doing is probably much more fun to code.