Sculpty exporter for Wings 3D

I get the funny feeling I've had this sense of deja vu before.

It's in JIRA as MISC-259. Please vote

Probably somebody made a mistake somewhere. Apparently 64x64 and below are stored lossy and 128x128 and above are stored lossless. That makes no sense at all ...

I tried your experiment with some other bitmaps. I didn't see lossless compression at 128x128, but the differerences were significantly smaller than at 64x64. So I think MISC-259 is essentially on target, and we all ought to vote for it.

I tried Blakars's little test with a 64x64 of my own. Uploaded to SL (beta grid), saved a copy of the file from SL to HD .... ran the test. I did not get any difference.

Now ... I did upload the original as a .tga file and resaved it as .tga ... not as .bmp files.

gryff

Well. At first I'd say it should not matter whether it's TGA or BMP untill I realised you probably have an alpha channel in the TGA while my BMP's are 24-bit. Maybe the alpha channel helps defeat compression. I'll do some more experimenting later on.

I tested uploads with TGA and BMP's with Alpha Channels. I see no improvement for 64x64 textures when I use TGA or if I add an alpha channel. If you have 0 artifacts using a 64x64 it's either a really favorable texture or a mistake is made in the steps to make the comparison map.

I checked the two files Blakar ... both are 24 bit .tga.

The original was created was a sculptie texture created using Blender.

I ran a test with a sculptie I created in Wings3d (the bowl I showed an image of earlier in this thread) too. It was 24bit .bmp file. I resaved that from SL (beta grid). Ran the 'difference' test. Again no difference. The .tga file I get on resaving is 24bit too.


gryff

Also note this on the wiki:

https://wiki.secondlife.com/w/index.php?title=Talk:Sculpted_Prims&curid=5179&diff=22409&oldid=22262

If you remove the llkdu.dll from the second life directory, it'll default back to OpenJPEG. It be good to see some tests without KDU to see how it affects sculpty images.

The precision between OpenJPEG (much higher) over KDU could affect the encode.

Also, you can use ImageMagick's "compare" to see differences in images beyond what the human eye can detect.

With your luck you should go out and buy a lottery ticket I see no probable cause. You can send me the textures if you want to and in that case I can try and find out why they are "special". Still in general any tests with 64x64 show tons of artifacts.

I have been considering the thought of how the encoding of uploads would affect this too and I've read some of the code. Now my personal expectation is that all uploads are lossless and the final encoding is done at LL's side. If it isn't so than we can indeed just alter the viewer to send valid lossless JPEG2000 files disregarding whatever LL wants to achieve storage wise. That would off course be a design flaw on their side. If you want things to be done in a specific way it's never wise to trust the user.

It might be just as easy for it to not use KDU in the encode of sculpties and default to OpenJPEG even if KDU is present. Will have to look into it more...

Never having won a lottery in my life .... I didn't believe I could get that lucky twice So I ran some more tests.

I created a file containing two layers (the original sculptie with a resaved sculptie on top) set the top layer to Difference, then flattened it. It looked all black. I saved this as a .psd file, then looked at it in 4 graphics programs: Photoshop7, Corel PhotoPaint11, PaintShop Pro9 and Gimp.

I opened it first in Photoshop ... as I think that is what you are using. Adjusted Contrast to +100 .. it went completely white (which I found a bit odd). I then tried it in the other three programs ... stayed black. But while using PSP, I ran the colour dropper over the unmodified merged file ... and it said there were tiny differences from true black (RGB:0,0,0).

Repeated this in all four programs ... dropper said there were differences.

While in Photoshop, I used the slider bar in the dialogue rather than type in 100. I saw colours flash by . It seems using a value of 100 caused problems. (Have since read Deanna Trollop's post ... so I guess I'm not the only one !)

Anyway ... this still left the other 3 programs still not responding to the Brightness/Contrast adjustment. In fact using it even less than 100 eliminated the tiny differences - the pixels all went to RGB:0,0,0 with the colour dropper test.

For the shear hell of trying something, I tried the 'Automatic Contrast Enhancement' in Photopaint - bingo!!! Tried this in PSP and Gimp too ... all produced the effect ... though there were differences. In PSP the effect was weaker ... required doing it twice and result was just white pixels. The other two produced a collection of coloured pixels with greater effect in Photopaint.

So ... the effect is there. Just have to get at it slightly differently depending on what imaging software you are using.

Anyone want to buy a lottery ticket?

gryff

I did a little research into this last week. The libsecondlife project includes a command line application, IA_ImageTool ,that will compress an image (using OpenJPEG) and upload it to SL. The application is mainly a demonstration of how to use libsecondlive libraries; there's no way to modify the JPEG parameters without recompiling the code. The application works, so I know SL will accept JPEG2000 encoded files from a client. I spent a little time trying to set the configuration parameters to do lossless compression, but the results, when viewed in SL, were even worse than those using the standard client. I didn't spend enough time to figure out where the problem was (my code, OpenJpeg or the libsecondlifes translation layer.) But it is something that someone who is comfortable in C#could pursue.

I noticed that the exporter defaults to 16x16. Can the size selector be restored? Thanks.

I tried swimming through the 16 pages if this discussion. I failed. When DolphPuns get Wings its a bit tiring. Doing OK for being out of my normal waters.

For those of us more comfortable in pornoshop or paint shop.. Is there a PSD out there with a UV map of our dear Wings Sculptie? Maybe a zipped set of them for each resolution? I sphere the answer will be no or yes, that was on the page after the one when you gave up reading the thread.

If it is the former, hopefully some skilled photoshopper will create one. If it is the latter, I am sorry and could someone IM me with the URL?

Yes, I do know there is a UV mapper program out there that I haven't had the best of luck with. Its probably moron, but I am still having trouble grocking which part of the texture of the sculptie prim relates to which. Even a simple visual graphic?

Yes, Hypatia has, quite a few posts back. But sphere not; they now have their own thread. See /8/5f/188429/1.html. If you just want the UV maps, without using Wings, you should be able to extract them from the .obj files.

I keep getting an unsupported mesh size every time I try to export.

Jason, the exporter doesn't work with an arbitrary Wings model. You have to work within the constraints described in the first post of this thread.

I installed version 0.98.36 of Wings 3D and version 053107 of exporter. I did the following: imported the 6463sphere sample and tried to export as a BMP. The exporter crashed. Here is the message:

Exporter crashed: function_clause
[{lists,nth,[1,]]},
{wpc_sculpty,'-similarFsLoop/3-lc$^0/1-0-',4},
{wpc_sculpty,'-similarFsLoop/3-lc$^0/1-0-',4},
{wpc_sculpty,similarFsLoop,3},
{wings_export,export,4},
{wings_file,'-export_filename/2-fun-0-',3},
{wp8_file,file_dialog_event,1}]

I also tried to sculpt the sphere to create a pot. I did and exported. Now, surprisingly, the exporter did not crashed, but the file created does not seems a BMP file and, by the way, its size is 1x6916. What I did wrong? Please, note that I was able to reproduce this behaviour every time.

Eadoin, the stack trace shows that you are somehow using Strife's version of the exporter, not the 053107 version from the first post of this thread. I'm not sure whether Strife is planning on maintaining his.

I am very new to this and if some kind soul one can straighten me i would be gratefull.

I installed the 0.96.36 wings and got the scuplty.beam(Strife's version) file in to the right diectory so I was able to export my .bmp file to the Sl textures diectory where i uploaded it in SL($L10) as an image/ texture.
I then in SL, got a prim, selected sculptured and applied my texture .bmp, which in Wings was a simple egg shape, but in SL the result was a rough old bumpy egg..not the pristune egg from Wings.
Was this the right way to export it into SL I ask myself?
I have no idea what to do with the 2nd wpc_sculty.erl file that came in the auxilly zip file?
should I do something with it?
Do I use the ERLANG program for something ?it sits there doing nothing?

The tutorial below is very good but helpfull in this area...his results are vey good though.
http://www.youtube.com/watch?v=lzgb2BrOjbw&eurl=http%3A%2F%2Fvamtv%2Ecom%2F
thanks in advance,

Bibi

Before you pay for the upload of a texture, look at the preview window and select "Sculpted". It will show how your sculpty will look like, once uploaded. Perhaps it can save you money from uploading "wrong" textures.

See the thread on Accurate Sculpting in general, and point #3 in
http://forums.secondlife.com/showthread.php?p=1533857#post1533857[\url] in particular

[QUOTE]I have no idea what to do with the 2nd wpc_sculty.erl file that came in the auxilly zip file? should I do something with it? Do I use the ERLANG program for something ?it sits there doing nothing?[/QUOTE]It is only there for someone who wants to make their own enhancements to the plug-in, or to see how it works.

Omei..thanks so much for ur swift reply,

You mentioned
"open your sculpty bitmap of 64x64 or smaller into a paint program and resize it to 128x128, _without_ interpolation".

I can view it in photoshop but I am not sure how to resize to 128x128, _without_ interpolation".

A brief explantion would be soooooo helpful,
thanks again,

Bibi