Sculpty exporter for Wings 3D

scratch what i said, I figured out the reason.

The exported sculpt map in Wings3d is upside down. I just finished working on a method for Carrara Pro which has the north pole on the north pole.

Going to do a few more tests, but seems its related to the vertical inversion of the map out of Wings.

Thanks for updating it.

Everything is tied to the point of reference and as long as there's no consensus on that it's rather hard to agree what is upside down or not. Talking about a "north pole" is for example hard. I can easily sculpt a ring and give both poles the same vertex. What's north and south in that case?

I think what we agree on is that the most intuitive way is the one where the flat texture looks ready to be folded around the sculpture. Meaning that we see from left to right what we'll see from left to right if the sculpture is in it's normal orientation. For such a shape we'll have a north and a south pole but sculptures are not limited to these applications.

Ideally once we've a clear definition all exporters will start producing similarly looking sculpt textures which can all be converted into common formats (obj would be suitable) and can be textured in the same way without the need of flipping anything.

I'll update the technical chapter on the Wiki with clear (I hope) definitions of everything and off course welcome all feedback. I do seek some feedback still for that anyway.

As an example of what I need feedback on: Let's say you've a basic sphere and want to texture it. What do you consider the most intuitive way to locate the seam where the left and the right edge of the sculpture texture meet?

My first thought would be to have the seam on the left (left for you when you're looking at the sphere). You'd then have your front picture on the left half of your texture and the back picture on the right half of your texture. Point is that there'll be 32 options of where you can put the seam and each exporter may pick its own.

I chose the orientation of the bitmap to make "up" in Wings correspond to "up" in SL. But I'm not positive that is the best choice, taking account how it might be used in combination with other tools. I'm open to changing it if it becomes clear that some other choice is better.

Blakar, you've obviously spent a lot of effort working out the details of how SL transforms the pixels in the bitmap file to an in-world shape. So you have any advice on the following issue?

If someone has a simple shape that is most easily modelled with an 8x8 mesh (for example), I could still have the exporter produce a larger bitmap if that makes the SL rendering better. But what is the best way to make use of those extra pixels? At this point, my best guess is to simply duplicate vertex values. But assuming that is the best strategy, there still is a question of how to duplicate them. Going from an 8x8 mesh to a 64x64 bitmap means each vertex would be represented by an 8x8 block of pixels. The simplest way to place that block would result in the pixel that SL was going to sample zt maximum LOD being on the corner of that 8x8 block. From the point of view of minimizing compression artifacts, that might be the worst choice. (I don't actually know that to be true.) But there is also a question of how the block positioning would affect the interpolation at 16x16 (or lower) LOD.

Do you have any insight on this?

I'm not really experienced with Wings to know how its orientation is - Carrara maps Z to the same axis as SL - maybe this is related?? I need to do a few more tests to be certain. Carrara's maps are definitely reversed from Wings. I mainly wanted to implement the Carrara method so I could make maps of larger size from spheres of smaller polygon sizes.

I have to mess with a baked texture map on my Carrara model, its on my list of things to do today. The export method is in early days yet, not quite a day old.

oh, duh,

you know, its probably best to just export the map to how its oriented in that program at the time - basically, it seems to me that north pole needs to be on the first row of the bitmap, and south pole on the last, and as long as it maps like that, its probably going to be ok.

I need to check some things though... mainly to test how the uvmapping differs from Carrara to Wings as it appears in SL - right now the poles look good, (maya exports with my polygon models were not as good there, as a side note ) but I have to see how its mapping with a single map.

If you put it on the edge JPEG compression will destroy it before it even drops LOD so that's not a good idea.

The solution is to center it. It's also best that for the pixels on the left edge you color pixels at the right in the same way just to be sure. Centering it defeats both interpolation and JPEG compression as it is the best way to assure that it needs to be compressed and interpolated quite a bit before it starts to distort the vertices that are always used.

The method above beats nearly any lossy compression + interpolation combination. It's not directly targeted at JPEG2000 or the OpenGL interpolation algorithm.

Attached image is a simple way to illustrate what you should do. Green and Red show where the poles are and there's 1 line that shows how individual vertices are done. The color wrap isn't necessary to defeat most interpolation or compression algorithms but it's a safeguard and the best way to use the extra pixels on that side.

Try it out and let me know. I haven't really experimented with it a lot. I'd be broke in a day if I uploaded all the special textures I think off during the day

hint: aditi grid do it on funny money

I think it just became easier:

/8/cd/187996/1.html

I did some tests. I started off with a simple shape made with an 8x8 mesh. (See U-Block.jpg.) Using the Gimp, I scaled the bitmap to 64x64 with no interpolation. Then I rotated rows and columns, fixing up the poles with cut/paste, to form the "centered" version you suggested. The next jpeg compares these two. Close inspection shows that there are differerences, but I would be hard pressed to say one was overall better than the other. This surprised me at first, but then I'm not sure the wavelet transforms used in JPEG2000 should necessarily give worse approximations to pixels on sharp color boundaries.

The next test I did was to compare a 64x64 bitmap against a 128x128 one. This gave a significant improvement. Based on your explanation that 128x128 is where interpolation kicks in, I figure that this is due to interpolation effectively averaging out compression errors.

I went on to try 256x256 and 512x512 bitmaps. There was a tiny amount of improvement as the size increased, but you had to look really close to see it.

My conclusion is that if you want to use sculpties with planar surfaces (as opposed to "organic" surfaces), there is a sweet spot at 128x128. There is also a little evidence that trying to manipulate the position of a constant block relative to the sampled pixel is not a big win. Of course, all this will change when and if we get lossless compression of small textures.

One other thing -- these comparisons were all made at maximum LOD. None of the variations I tried were significantly better or worse at lower LOD.

now that is very cool! Best idea yet, to just make it an importer to the client.

regarding exporter - Just did my texture baking tests in Carrara and I don't have to flip the textures at all to fit on a Carrara exported sculpt. So definitely I would suggest to change the exporter to have the north pole mapping from the top of the sculpt map instead of from the bottom.

I can't. My self compiled 1.16.0.5 client crashes while connecting. And I want to use that one because it has additional debug output for sculptures (It informs me about LOD, texture sizes ... of all the sculpted prims it renders).

I guess I could set up a separate environment with the older beta source and then reapply just my sculpt patches but that's too much hassle for now

I know. JPEG was very bad for boundaries and JPEG2000 is improved for it. Still an image tends to have it's data always ordered so that you need to benefit patches of colors and hence boundaries tend to get messed up most easily.




I must've been unclear on the interpolation stuff. Interpolation only kicks in if the LOD drops. So if you use a 1024x1024 sculpt texture the viewer will only sample your points from a lower sized texture once LOD drops. At the lowest LOD it'll hence still use a 256x256 to create it's 9x9 set of vertices. I'm going to propose to patch this though as it's silly.

Given the above I assume the difference is due to JPEG compression as interpolation did not come up as you tested at max LOD.

Would you mind posting the related textures? Personally I expected much better results for the 64x64.

Please shut up any further in the builders forum and go to
https://wiki.secondlife.com/wiki/Talk:Sculpted_Prims
to talk about your bloody sculpies

Here they are. I've included more than those I showed rendered in SL.

Note that I did my tests on the beta grid (1.17.0.107).

Hey it all worked! I got the alpha at first on the front page, but once I had the right version the plug in worked.

Wings3D used to be "Nendo" so if you search for Nendo Tutorials you can get some great tutorials.

I should be reading the source, too. Can you give me a pointer to the relevant part(s)?

Thank you, Adda. Notes of appreciation always give me a lift. But as for making sculpty babies together, ... *blush*.

Cheers!

Omei, I don't remember how far back in the thread it was mentioned but you said the updated version of the exporter had the "export selected" option taken out, yes?

The reason having that option is usefull if you have other objects in the scene that you don't want exported. For example I tried making some shoes today and in order to get the foot shape right I imported the SL avatar OBJ file, lopped off a foot and used that as a reference for shaping the shoe. Obviously if I'd tried to export without selecting my sculpt mesh, the export would fail.

Also, I'm having trouble finding the link to Strife's version of the exporter and I'd like to link it on the wiki.

Is this it: http://forums.secondlife.com/attachment.php?attachmentid=25721

I uploaded the 2 64x64 and the 128x128 and in wire view it's clear that something is wrong with the compression. The 128x128 has hardly any shifts while in the 64x64 the vertices shift significantly. So basically anything below 128x128 is compressed more. For now my advise would be to switch to exporting 128x128 instead of 64x64.

I'm going to file a bug in JIRA for this.

Good point. I'll probably put it back in and put a little effort into generating a more meaningful message when someone does it by mistake.

I believe his most recent version is at /8/20/183764/4.html#post1516220/8/20/183764/4.html#post1516220