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

All times are UTC




Post new topic Reply to topic  [ 55 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
 Post subject:
PostPosted: Wed, 23-09-09, 21:36 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
ElChristou wrote:
t00fri wrote:
OK, here it comes (Click for somewhat bigger display)...


Tx, I'm relieved, I do have the very same pinch.

BTW, is this script good for any .tab files or it was just done for Phobos?


In the present form my script is good for Phobos, yet may be good for others.
But of course, I am thinking about a much more versatile version, since Perl conversion into CMOD format will become an increasingly important task. Think of all these small non-spherical moons floating around Saturn, for example.

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 23-09-09, 21:46 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:
...Think of all these small non-spherical moons floating around Saturn, for example.


Exactly if the shape models do exist it's potentially a very useful tool.
If only something could be done to at least smooth the pinch at geometry level... :|


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 23-09-09, 21:47 GMT 
Offline
User avatar

Joined: Mon, 07-01-08, 13:30 GMT
Posts: 367
Location: Switzerland
Making CMODs in Perl is a neat way of doing things... used it myself in the W UMa binaries add-on, where I output the triangles in the form of trifans and tristrips... the Wiki claims these save space but not sure if this applies to the binary version of the CMOD as well?


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

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
ajtribick wrote:
Making CMODs in Perl is a neat way of doing things... used it myself in the W UMa binaries add-on, where I output the triangles in the form of trifans and tristrips... the Wiki claims these save space but not sure if this applies to the binary version of the CMOD as well?


Yes, I read that as well, but didn't experiment with these. Good you did. In any case the (binary) cmod files tend to get big anyhow when the number of vertices grows substantially . The published Itokawa shape files are a good illustration.

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 23-09-09, 22:02 GMT 
Offline
User avatar

Joined: Wed, 05-09-07, 0:09 GMT
Posts: 57
Location: Seattle, WA, USA
ajtribick wrote:
Making CMODs in Perl is a neat way of doing things... used it myself in the W UMa binaries add-on, where I output the triangles in the form of trifans and tristrips... the Wiki claims these save space but not sure if this applies to the binary version of the CMOD as well?


Yes, triangle strips are preserved in the binary format. The ASCII and binary versions of the format are functionally identical: ASCII is easier to generate with scripts (or even by hand), binary is smaller and considerably faster to load.

Tristrips can in some cases improve rendering performance, especially when optimized to take advantage of the GPU's vertex cache. For very regular meshes like Phobos, it's probably a wash--the vertex access patterns will be effectively identical unless you go out of your way to generate triangles in some perverse order. The size benefit is still real worthwhile, however.

--Chris


Top
 Profile  
 
 Post subject:
PostPosted: Wed, 23-09-09, 23:42 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
Isn't there a better way of displaying these models. Like using something other than a triangle. So there wouldn't be a polar pinch? Reason I ask, there will be some fascinating data available soon when the LRO spacecraft sends more data from the Lunar poles. The MRO spacecraft also is sending back a lot of data from the polar regions of Mars. It would be nice to have a topographic maps of this new data without all the pole pinching.
cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 24-09-09, 0:12 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
chris wrote:
This will work if the vertices are duplicated every time they're used in a triangle. It's simple, but results in a larger model that will be rendered more slowly. However, cmodfix should take care of removing the duplicate vertices if you specify the --weld and --uniquify options.

Yes, this is what happens. With the Blender script, every line that is printed out is a vertex from a face. I think each face shares 1 vertex with a neighbor. Some share 2 verts. So that is a lot of duplication. But I'm not aware of another way to read the file. I suppose I could read each vertex, print it out, and then construct a triangle list. Some day I may actually attempt it.

Somewhere back in the beginning of this thread, I noticed a mention that the z and y vertices are swapped in Celestia. I used to right the coordinates out as x, y, z and the normals out as x, z, y. Recently I updated this script and write out the line with both location and normals as being x, y, z. Should I write both out as x, z, y?
cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 24-09-09, 1:28 GMT 
Offline
User avatar

Joined: Mon, 03-09-07, 23:01 GMT
Posts: 432
Location: Tuscany, Tyrrhenian Sea
Ahem, these scripts are very interesting but I wonder whether could be wrote also in LUA language, because a Perl interpreter for Win require to expand a 30 Mb .exe file! I'm very perplex whether to install (possibly) 300+ Mb for reading ONE page code. :roll:


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 24-09-09, 1:35 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
Concerning the pinch, no way to code an auto decimation of a predetermined ranks of poly from the pole?
Something like this:

original geometry:
Image

after decimation on the first 4 ranks:
Image

Note we do use here ONLY original points so despite we may end with an arbitrary choice of points, they are still part of the original data plot. I tend to believe this should not be a problem because the actual over dense structure is not in relation with the overall model's density of vertex...

In the example above, from 20 triangles at first rank we end with only 5 and this should reduce dramatically the pinch effect...
Could something like this be possible?


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 24-09-09, 2:33 GMT 
Offline
User avatar

Joined: Thu, 25-10-07, 15:20 GMT
Posts: 992
Location: NE PA, USA
With a modeling program, I suppose you could map each new triangle to a UV. I don't know how it would be done automatically. I was looking at an ico sphere. There you have 5 triangles and no pole pinch. Like a bee's honey cone. But can that be mapped or run in Celestia or graphics hardware? Here are 3 images.
First image shows 2 subdivisions.
Image
This image shows 7 subdivisions.
Image
A close up to show the triangles at the north pole of the sphere.
Image
Would using this be possible. I haven't tried to render a texture on it yet.
cartrite


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 24-09-09, 3:46 GMT 
Offline
User avatar

Joined: Wed, 05-09-07, 0:09 GMT
Posts: 57
Location: Seattle, WA, USA
ElChristou wrote:
In the example above, from 20 triangles at first rank we end with only 5 and this should reduce dramatically the pinch effect...
Could something like this be possible?


Yes. It adds complexity to the mesh generation tool, but I think that it's worthwhile for two reasons:
- It reduces interpolation artifacts near the poles
- It reduces the triangle count in the model

For my high resolution Itokawa models, I wrote a script that generated a model from heavily subdivided octahedron, with just four triangles joining that the pole. But some of the vertices in that model were interpolated. In fact, I think that with your scheme you might end up interpolating as well. The radii are spaced 2 degrees apart in longitude, so you've got 180 points around the equator. Each decimation step removes exactly half the triangles, so:

180
90
45
22.5 ...oops..

How do you subdivide once you've got an odd number of faces in a ring?

--Chris


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 24-09-09, 10:10 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
fenerit wrote:
Ahem, these scripts are very interesting but I wonder whether could be wrote also in LUA language, because a Perl interpreter for Win require to expand a 30 Mb .exe file! I'm very perplex whether to install (possibly) 300+ Mb for reading ONE page code. :roll:


As a most powerful cross-platform scripting language Perl is automatically part of the system installation already for ALL Linux and MAC OS computers worldwide! It is simply by mistake that Perl is not an automatic installation standard on Windows machines, too. My Perl installation for Windows is just 45 MB altogether (expanded!). It runs under the CYGWIN Linux layer which is great by providing in addition a clever UNIX shell (bash, zsh) in a great console for Windows, as well as ssh networking etc.

I bet that many more users have Perl installed (often without knowing) than LUA...

I will certainly not spend my time rewriting my scripts to LUA, given that most of our BIG workscripts for Celestia are written in Perl, too: My galaxy extraction , my binary star extraction, my globulars extraction, Andrews' HIP star extraction, Andrews W UMa binaries add-on, etc.

Altogether this concerns MANY thousand lines of Perl code ;-)

And LUA is simply not rich enough, if you compare with the amazing amount of modules for Perl. Where is the special math function module, where is the quaternion calculus, where are all the convenient ftp and WEB services etc. in LUA? LUA is fine for just a little script here and there but nothing really big. Too many important application libraries are simply lacking for LUA. Perl can be read like text and be learned in a few hours.

As concerns myself, my present CMOD script in Perl is just a start for a much more versatile Perl scripting project to convert ANY available scientific shape model data to CMOD (ascii) format. Further fancyness could be an improved tesselation near the poles implying a significant reduction of the pinch problem for models etc.

There is far more easy and most useful applicability for an installation of Perl than merely running a 1 page CMOD script ;-)

Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 24-09-09, 12:15 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4666
Location: Hamburg, Germany
Chris wrote:
Yes. It adds complexity to the mesh generation tool, but I think that it's worthwhile for two reasons:
- It reduces interpolation artifacts near the poles
- It reduces the triangle count in the model


It appears as an easy task to apply in my CMOD conversion script similar polar optimization ideas as are long implemented in my VT tile code (F-TexTools) in the polar regimes. In the (i,j) loops that serve to define and set up the faces, it is easy to decrease the number and increase the size of tesselation triangles towards the poles, i.e. when i approaches 0 or 90. In each row, the reduction of active vertices as required for no/little pinching can be simply calculated in terms of the known, decreasing circumference towards the poles.

That would be a task that takes 30 minutes at the most...

But here is something which is not entirely clear to me:

In principle there are two possible sources for visible pinching effects: shape-model based pinching and texture-based pinching. I am not sure to which extent the two kinds affect each other and which is more severe visually.

Any solid knowledge about this issue around here?


Fridger


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 24-09-09, 12:50 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 22:52 GMT
Posts: 2727
Location: France, South, not far from Montpellier
chris wrote:
...Each decimation step removes exactly half the triangles, so:

180
90
45
22.5 ...oops..

How do you subdivide once you've got an odd number of faces in a ring?


That's where you gurus have to think in a clever solution! Sorry to not be able to think in something but I guess the solution use some maths skills I don't have... No way to relocate in such case the positions of the points to the closest location avoiding odd numbers?

t00fri wrote:
But here is something which is not entirely clear to me:

In principle there are two possible sources for visible pinching effects: shape-model based pinching and texture-based pinching. I am not sure to which extent the two kinds affect each other and which is more severe visually.

Any solid knowledge about this issue around here?


Solid I'm sure not but from what I see with the new Phobos mesh we have, the geometry pinch depending on the lightning (worst when no ambient light is used) is a problem; in such case the good work with anisotropic filtering at texture level can be washed out by this geometric feature...
So to me, ideally both sources of problem need to be addressed to get a perfect pole.


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 24-09-09, 18:17 GMT 
Offline
Site Admin
User avatar

Joined: Thu, 30-08-07, 21:25 GMT
Posts: 265
Location: Paris, France
Some cleaning!

All about Perl in Windows can be discussed in the Docs & Tutorials forum here:

http://forum.celestialmatters.org/viewtopic.php?t=338


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 55 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