It is currently Sun, 15-12-19, 15:32 GMT

All times are UTC




Post new topic Reply to topic  [ 47 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Tue, 29-09-09, 12:37 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
ElChristou wrote:
cartrite wrote:
I think you are missing my point. I'm trying to show that there is a way of reducing the triangles "via a script" in a very complicated way. I've seen Blender do this with the reducer script. All texture coordinates are preserved along with vertex locations. It just rearranges the triangles somehow.
cartrite


Blender is not the only soft to use such decimation process. The goal is to respect the geometry, joining 2 closer points and this in general is done in several passes. From my experience (not in Blender), the result is pretty effective BUT you also end with quite some artifacts (bad positioning of points) you can only fix by hand. I don't know if it was the case for John, but if it is that represent too much work for a general tool...

So this is a well known process but not full proof. Oh well.

Still, from the results I've seen from Fridger's latest script, I think if the texture coordinates are mapped to the new triangles, it would look a lot better. It seems that the texture coordinates are written before the triangle list is constructed. So some of the triangles that were there for the UV coordinates are culled and that throws off the mapping. Maybe the script should go through 2 passes, create a temp file or something and then remap the texture coordinates after the triangle list is constructed in the temp file?
cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 12:42 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
t00fri wrote:
cartrite wrote:
I think you are missing my point. I'm trying to show that there is a way of reducing the triangles "via a script" in a very complicated way. I've seen Blender do this with the reducer script. All texture coordinates are preserved along with vertex locations. It just rearranges and reduces the triangles somehow. With this method, there is no pole pinching and the texture is seamlessly mapped.
cartrite


OK Steve, you may well be right ...

yet, it would have been great if the first sentence of your post was

"I'm trying to show that there is a way of reducing the triangles "via a script" in a very complicated way." ;-) . Why hiding such clear sentences?

Instead your post started quite cryptical:

"Here are 3 images..."

Fridger
I see your point. English/writing was never my strong point. I find writing more difficult than , say, rebuilding a front end on a motor vehicle.
cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 12:54 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
cartrite wrote:
t00fri wrote:
cartrite wrote:
I think you are missing my point. I'm trying to show that there is a way of reducing the triangles "via a script" in a very complicated way. I've seen Blender do this with the reducer script. All texture coordinates are preserved along with vertex locations. It just rearranges and reduces the triangles somehow. With this method, there is no pole pinching and the texture is seamlessly mapped.
cartrite


OK Steve, you may well be right ...

yet, it would have been great if the first sentence of your post was

"I'm trying to show that there is a way of reducing the triangles "via a script" in a very complicated way." ;-) . Why hiding such clear sentences?

Instead your post started quite cryptical:

"Here are 3 images..."

Fridger
I see your point. English/writing was never my strong point. I find writing more difficult than , say, rebuilding a front end on a motor vehicle.
cartrite


Actually, from my frequent communications with you, I wouldn't say so ;-) . I think your explanations and observations are usually very well written (even for a non-native like myself). But it's really a bit generic of your style that you tend to come forward with the crucial sentence about the purpose of your post only in your second one...

Here is another very recent example, that made me smile a bit
Cham wrote:
Just a question (I'm curious) : why are you doing this ?


Well so far we have always managed to communicate ;-)

Fridger


Last edited by t00fri on Tue, 29-09-09, 13:11 GMT, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 12:58 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
t00fri wrote:
...At least, when I look at my complete Phobos model with the new pinch improvement AND using a zoom level that is ADEQUATE for a 4k texture, then I can't help, my Phobos looks simply perfect


Hmm... Then I'm lost. I use a 2k map for my "excessive graphical detail" without utterly exaggerated zoom and as far as I can see I cannot say what is on the shot is perfect... What's going on here? Do you have such "smoothed pinch" on your side or not??


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 13:09 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
What I am saying is that nowhere I can see any remaining traces of the pinch effect with the model generated with the latest version version 1.2 of my script and my 4k Phobos texture. This holds provided that I apply a magnification respecting the theoretically maximal magnification (= natural pixel size!).

That's the analog of hitting 1 in GIMP when you have loaded an image.

Of course I see some traces ("pinch feelings" ;-) ) when I zoom in much further.

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 13:30 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
Just as a future reference, this is a perfect display (wireframe) of my no-pinch triangle network in action (around the North pole). I have focussed precisely on the region that gets modified from Jstep=1.

Click for Big
Image

It serves also as a nice reality counter part of my earlier drawing B) in the planar "simple rectangualr" (i,j) basis:

Image

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 16:05 GMT 
Offline
User avatar

Joined: Sat, 13-10-07, 18:18 GMT
Posts: 373
Just for what it is worth here, I can't see any pinch effect on my own Phobos model. :wink:

Just FYI... Of course, the Good Doctor also showed me how to create the thing too. :)

Thanks, Brain-Dead


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 16:56 GMT 
Offline
User avatar

Joined: Wed, 05-09-07, 0:09 GMT
Posts: 57
Location: Seattle, WA, USA
Fridger,

Your system of reducing the subdivision in longitude is quite clever--sort of a prime factorization of the original subdivision level as you approach the pole. The results are much better than with the original and more straightforward tessellation. I've got a few further suggestions that may or may not be useful.

First, there's some region of texture space near the poles that will not be applied to the model because it's mapped to the degenerate triangles. Since the radii are given at intervals of two degrees in latitude, the affects of these gaps will be noticed within +/- 2 degrees of the pole. Would it work to add an extra row at, say, 90-0.25 degrees and -90+0.25 degrees? The vertex position and texture coordinates would simply be linearly interpolated from the +/- 88 degree rank. This should restrict the region affected by texture 'gaps' to only the places within 0.25 degrees of a pole. However, this generates some rather skinny triangles and may require filtering help than even 16x anisotropic filtering can provide.

Second, the maximum level of anisotropy is currently set to 8x in Celestia. We should probably increase this to 16x, which is commonly support by hardware. Change the following line in texture.cpp:

texCaps.preferredAnisotropy = min(8, maxAnisotropy);

This extends the effectively filtered region from latitude acos(1/8) up to acos(1/16) (82.8 degrees to 86.4 degrees.)

Finally, it looks like the remaining geometrical (as opposed to textural) 'pinching' is simply a result of anisotropy in the sampling of radii that remains even after decimation. I don't think that there's any way to get rid of it without a more 'destructive' decimation scheme that uses some filtering to generate new vertices at ideal spacings. You gain a better visual appearance, but sacrifice some data transparency (though not all of it, since the source code for the processing script is available.) I don't doubt that we have a philosophical difference on the proper approach here. :) Personally, I'd reduce the longitudinal tessellation by a factor two as soon as the value aspect ratio of the quads was less than 0.5 and use interpolated vertex positions. I can also understand why one might not choose to do this and instead use your current approach, which appears to offer an optimal tessellation without introducing interpolated vertices.

--Chris


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 18:32 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
Thanks Chris,

for this highly useful evaluation and your further tips. That's the kind of constructive feedback one dreams about!

I'll go through your suggestions one-by-one and will see what I can implement. With my old card here, the maximum anisotropy filtering is only 8x but I can display my new office machine (9500GT) on my screen at home with TightVNC in perfect quality and speed any time ;-) . (Since TightVNC supports CUDA it is by far preferable to Remote Desktop which doesn't, but is faster)

While until recently my (considerable) knowhow about tesselation was mainly located in abstract vector spaces ;-) and in connection with spline surfaces, I am still learning the more practical aspects now ;-) . I actually noted that the internet resources about this basic task in computer graphics are VAST. So I am sure I will be able to soon implement a few of these more fancy concepts. The problem then might be that Celestia does not support that more fancy stuff (yet). I have already learned that tesselation tasks can be nicely dedicated to parallel GPU calculations. That should however only become relevant for CelestiaNextGeneration ...

What I am most interested in next would be to realize a transparent, efficient and flexible dynamical tesselation algorithm for general (scientific) shape models at the level of Perl scripts. While C++ might be a tough competitor due to specialized library availability, Perl has a lot of advantages, too. Let's see...

My specific problem here is widely discussed in the net: namely what's the best procedure when tesselation patches of different levels meet (precisely happening in my anti-pinch recipe!) . One interesting proposal was to use a "dyadic snap function" that moves "hanging nodes" (my purple dots above in figure A)) always to the nearest connected nodes. You have an opinion about that?


Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 19:28 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
t00fri wrote:
...That's the kind of constructive feedback one dreams about!


Got the message, tx for the slap in the face! :lol:
No more trash-feeback from me! :oops:

(but still curious to see the model we talk about via mail!)


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 20:42 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
ElChristou wrote:
t00fri wrote:
...That's the kind of constructive feedback one dreams about!


Got the message, tx for the slap in the face! :lol:
No more trash-feeback from me! :oops:

(but still curious to see the model we talk about via mail!)


The code is already in the making, but my daughter was at the phone during the last 1.5 hours ;-)

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 23:17 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
Hi friends,

following ElChristou's persistent encouragement (thanks Christophe!) ;-) I have now enlarged the pinch correction zone substantially.

++++++++++++++++++++++
Altogether I am VERY happy with the result. Now I really don't manage anymore to spot
any clearcut pinch signatures!
++++++++++++++++++++++

As I outlined above, instead of the narrower correction domain in version 1.2 with the triangle size sequence,

Code:
jstep = 38, 18, 9,3, 1 and then 1's

I have now prepared version 1.3 with a considerably slower decrease towards jstep=1,
Code:
jstep = 36, 18, 9, 9, 9, 9, 3, 3, 3, 3, 1 and then 1's

i.e I have inserted a few 9's and 3's. This way the decrease of jstep's is getting closer to the theoretical decrease for a purely spherical model.

Here you can see nicely the larger extent of the circular pinch correction zone around the North pole:
Image

and here is a close-up for seeing the effects of the inserted 9's and 3's:
click for BIG

Image

This time, let me demonstrate the amazing effects of the pinch correction with three MPEG4 (XviD) videos. They are not very long, but depending on your line speed you might have to download them before playing. Notably if you are in Europe since ibiblio is in the US...

Watching the Sun's effects on the surface of Phobos close to the North pole at high zoom is a VERY sensitive probe on pinch effects. Here we go...


The video format works fine both with the VLC player (Windows, Linux) and with the Windows Media player.

++++++++++++++++++++++++++++++++++++++++
Finally, again the download archive with my 1.3 Perl script update, including the scientific input data, the resulting ascii and binary CMOD shape models, where the binary version can just be plugged into Celestia.

http://www.celestialmatters.org/users/t ... os_1.3.zip

++++++++++++++++++++++++++++++++++++++++

Let me know,
Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 23:44 GMT 
Offline
User avatar

Joined: Mon, 03-09-07, 23:01 GMT
Posts: 432
Location: Tuscany, Tyrrhenian Sea
chris wrote:

.
.

First, there's some region of texture space near the poles that will not be applied to the model because it's mapped to the degenerate triangles. Since the radii are given at intervals of two degrees in latitude, the affects of these gaps will be noticed within +/- 2 degrees of the pole. Would it work to add an extra row at, say, 90-0.25 degrees and -90+0.25 degrees? The vertex position and texture coordinates would simply be linearly interpolated from the +/- 88 degree rank. This should restrict the region affected by texture 'gaps' to only the places within 0.25 degrees of a pole. However, this generates some rather skinny triangles and may require filtering help than even 16x anisotropic filtering can provide.

.

.



During some experiences with metaball objects (voxel modelling - marching cube, tetrahedrons algoritms) I've noticed that it's possible to reduce strongly the poles'pinching by an operation of smallest
flattening (hammering) just within the ranges of which Chris says (and even morer small, so to not prejudicate the scientific's data shape; in this kind of modelling they depends upon subdivision's levels). So, I wonder whether the pole's vertex might be "lowered" from the imaginary "sphere path" on which insist and brought to meet the lastest tassellation's triangles bases (that is, the radius of the pole's vertex = radius of the last base tassellation's triangles).


Top
 Profile  
 
 Post subject:
PostPosted: Tue, 29-09-09, 23:52 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
Fenerit wrote:
During some experiences with metaball objects (voxel modelling - marching cube, tetrahedrons algoritms) I've noticed that it's possible to reduce strongly the poles'pinching by an operation of smallest
flattening (hammering) just within the ranges of which Chris says (and even morer small, so to not prejudicate the scientific's data shape; in this kind of modelling they depends upon subdivision's levels). So, I wonder whether the pole's vertex might be "lowered" from the imaginary "sphere path" on which insist and brought to meet the lastest tassellation's triangles bases (that is, the radius of the pole's vertex = radius of the last base tassellation's triangles).


Sorry, I have not yet considered Chris' propositions in detail, since I first wanted to try out the above enlarged pinch correction zone, following Christophe's encouragement. In the post above yours I have just summarized my results of this a few minutes ago (cross posting?). Tomorrow, I'll look into Chris' proposals.

I'll have to shift your question also to tomorrow, since here it's now pretty late...

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 30-09-09, 0:51 GMT 
Offline
User avatar

Joined: Mon, 03-09-07, 23:01 GMT
Posts: 432
Location: Tuscany, Tyrrhenian Sea
Sorry Fridger, when I wrote the last post was that of Christophe. Have a good night!

EDIT LATER

Nope! was that of 1.5 hour daughter's telephone. :shock:


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 47 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group