Sculpty exporter for Wings 3D

Your bmp file is a 32-bit image, which the importer isn't expecting. In the next version of the import/exporter, I'll try to at least add more meaningful error mesages. In the case of 32-bit images, I could add that capability if there is a significant need for it. Will you have trouble generating a 24-bit bmp file? (There is nothing to be gained by using a 32-bit image, since SL ignores the alpha channel for sculpties.)

That image imports fine for me. If Wings 3D doesn't like 32-bit bitmaps then it's an issue with it's bmp importer. Sorry :-/

Omei Turnbull, can I be the mother of your sculptie prim babies?


This makes it SoOOooOOoo easy.

/me makes note to send Omei some L$.

A

LittleJim, in case it wasn't clear from the context of Strife's post, his importer (/8/20/183764/4.html#post1516220) does import your bitmap. So there is a bug in mine that I will track down.

(I don't know what made me conclude you had a 32-bit bitmap. Brain must have shut down for the night.)

This is just a mild guess at *some* of the problem.

You say sculptie was made with 64x63 ... yet when I count the slices in the w3d image ... looks like 32+. I don't know how you made the bowl shape, but looking at the sculptie it looks like you may have two layers of slices overlapping ... which add in the jpg compression variations ... you get that mess. you have to keep the inside and outside surfaces at least some distance apart.

gryff

I was beginning to think that. I tried 4 different graphics packages all said was a 24bit file and all crashed on attempting to import it.

By the way, it seems easy to install a plugin in Wings3d, anyone know how to remove one ?

(I wanted to try Strife's importer too.)

gryff

More or less yes Omei. Except I use an .obj file's ability to give different regions different colours. Then when I use UVMapper I can select by materials(colours) then create a map for the regions. That way I can identify which parts are where.

It can get quite tedious if the final sculptie shape is severly different from a sphere.

People should perhaps know that if you buy the UVMapper Pro ($60US) it can be used as a realtime 3d viewer while you paint in Photoshop, Paintshop Pro or Corel Painter. (See tutorials at the website). It is a little cheaper than buying one of the 3d painting programs.

gryff

Just copy the new one over the old and restart Wings. There's no hidden registration process.

TY Omei

For cypher have attached my effort at creating a bowl (with texture)



gryff

ooo nice!

That's something about the exporter for Wings - it always gets the poles right. The cylinder method I tried in other programs failed miserably.

Hi Gryff and Hi Omei

Gryff I wished i where there where you are with the suclpty's

There was something wrong with the forum-email-feature.
I did not realized this thread has been updated for me,

THX A LOT FOLKS

I attached the 2 files in the Zip-archive:

SL_Sculpty_64x63_01.wings
The native sphere fresh baken from Wings3d

SL_Sculpty_64x63_01.bmp
The exported BMP of the 64x63 sphere

Hope this helps in researching my prob..
Thx again,
take care and
HAVE FUN
Cypher Black

Gryff Richard wrote :
By the way, it seems easy to install a plugin in Wings3d, anyone know how to remove one ?

Go to :
C:\Program Files\wings3d_0.98.36\lib\wings-0.98.36\plugins

delete the right plugin and (re-)start Wings3D

Worked this way for me
take care and
HAVE FUN
Cypher Black

Hypatia, I duplicate the values for the poles across the whole top and bottom rows. Did you do something else?

I tried the UV method in Blender first - using a cylinder and baking the texture. That's when I realised its got to be a sphere, and the uvmapping has to match how I did it for the Wings sphere that I posted here.

I've now had my models made with the Wings sphere exported in several programs, and I found the vertex exporter in Wings to gain a more accurate approximation of the model (comparing them to the textured preview in Zbrush and UVMapper). Something else I realised - the UVmapping does not come in via the UV method - SL applies its own funky spherical mapping anyway, so the UV as I did it for the sphere posted here will yield a texture that exactly fits the model in a 3d texturing app or by baking textures to the uvmaps.

Cypher, the sphere files you just posted illustrate the effects of SL only supporting 8 bits per coordinate. I don't think there is anything the exporter can do it improve on that.

On the other hand, I think the in-world picture of your bowl you posted in /8/20/183764/10.html#post1527490 illustrates a different phenomenon, probably the effect of JPEG compression. If you post the .wings file for the bowl, I can test my theories.

And I think it'll be right for cylindrical type, but I think it was incorrect for the sphere stitching, and that the current version on the wiki is correct.


So it seems that there is something odd going on. I was going to say that it is just jpg compression artefacts... I sent you in world a huge blown up version of the texture, shifted over so that the sample points are in the center of blocks of colour, and you can upload it to SL and see that it's really just a sphere. The way to check should be to use the preview as sculpty tool, which I believe is before compression. However, with your 64x64 I again get weird spikes on preview. So I dunno.

I don't think the current Wiki is any more correct with respect to whether odd numbered pixels contribute to the shape. My experiments suggest that there is interpolation going on between odd and even pixel rows and columns, but that this interpolation isn't the same for all parts of the sphere. Every time I come up with a theory to explain it, I easily find a counter-example. Sigh.

I've update the plugin to address the following issues:

* Thanks to Cypher Black's prodding, I improved the exporter's choice of pixel values. The difference isn't huge, but some curves, especially near the poles, should look a little smoother in SL.
* Made the importer tolerant of extra bytes at the end of the file, so it could import LittleJim's bitmap.
* Removed the sculpties option from the "Export Selected" menu, since it was just causing confusion and wasn't really useful.
* Changed the "Unsupported mesh" notification so that it appears in a neat little dialog box instead of as part of an "exporter crashed" backtrace.

See the first post in this topic for the new file.

Interpolation is indeed used but only for lower LOD. Wiki now has all the dirt on that too

If you manage to create textures that give results which are inconsistent compared to what the Wiki states just yell somewhere and it'll get picked up. The closer to my ear you yell the more chance I'll dig up the related code to see if we're still missing things in the Wiki.

At the time of your tests the Wiki didn't mention that line 0 was the bottom row of your texture hence instead of changing the pixels that are not used you changed the pixels that are used. It was an unfortunate side effect of me writing the Wiki based on the source code. When you're reading source it's crystal clear whether he reads odd or even rows but I never exhaustively checked if the code agreed on where to start counting

At the highest detail level, sculpt texture rows 0,1,3,5,7,9.. etc seem to be used to map the vertices, and not rows 0,2,4,6,8 etc, as stated in the wiki.

Hypatia, I've been trying out Wings and using your UV map/UV Mapper Pro/Photoshop to do the textures; everything looks fine on the OBJ but when I upload to SL I have to apply a vertical flip to the texture to get it to line up properly. Not sure if this is a quirk of SL or the mapping.

It's an SL quirk unfortunately. But not a serious issue.

I was aware that rows in a .bmp files are normally numbered from bottom to top, but I thought my tests had shown that there were still examples where interpolation was occurring with the 64x64 bitmap. I can't reproduce that result now though, so I'm willing to believe I was just getting mixed up.

Thanks for helping me get this straight.

Reread the Wiki. Line 0 is the bottom row. So if you start from the top the first one is 63, then 62, 60,58 ...