Blender Sculptie Importer - Attached

domino, any chance you could mirror the git repository to mercurial? I'd say it is more convenient for windows users, at least for now -- mercurial has a GUI a la TortoiseSVN; git is still only available via cygwin...

http://code.google.com/p/msysgit/

Does that help?

Thanks for the link domino, it might help others meanwhile, cygwin is behaving again on my end..

Q. If I maintain the centerpoint of a sculptie instead of letting the exporter calculate a new one, I will loose some of the available resolution correct (specifically, if I keep a centerpoint that is quite a bit offset from the bounding box center)?

Yes you will lose some resolution of the sculpt map. It's there for when trading resolution for an offset center is the best option. Doors are the obvious application for it as you can precisely place the hinge so that opening the door is just a rotation in SL.

Ok, good. :]
Yes, %HOME% is set, its of particular advantage on Vista 64 systems where the Virtual store can put things in (initially)unexpected places..I just thought i should mention it for the sake of documenting it here.

I have never tried but can you just put the scripts in a subfolder such as /.blender/scripts/domino/? That would make keeping track of them easier.

Any child folder of .blender\scripts gets parsed. So I guess that's an option, yes.

http://blog.machinimatrix.org/2008/07/12/the-blender-installation-guide/

Gaia covers setting the user python path in her installation tutorial

Question - I've been trying to work out ratioed sculpts with the current version of export scripts, and Blender 2.47. Unfortunately, for some reason, the maximum number of faces I can enter for either x or y dimension is 32. Am I doing something wrong here? It does this whether multires is 0 or 2.

Use the release candidate scripts, those support oblong sculpties and have lots of other new features to make things easier.

http://dominodesigns.info/second_life/blender_scripts_git.html

ok - so do i run that command through a command prompt? I'm in my Blender script folder, typing git clone git://dominodesigns.info/dd_scripts.git blender_scripts , but it's saying 'git' is not recognized as an internal or external command, operable program or batch file.

Do i need to download some sort of downloader to run that 'git' command?

Cool!

Do i have to do anything special when i export? Render>Bake Second Life Sculpties, right?

It doesn't seem to pass a sculpt map to the UV/Image Editor on my end

Woot - working now. Thanks muchly!!

I have a weird problem with the older script that is not an issue for many, but for me it is kind of an issue with this one project.

I would like the 'seam' of the sculpt to be moved to another side/axis. It is right on the side and makes it a tad difficult to texture and I need an easier texture map method so folks can easily make their own texture. I tried rotating, mirror etc. and I keep getting the same sculpt map. I tried another prog to flip it and it did not work out either lol. So I am wondering how i can make the surface texture of the sculpt to be starting and ending at 90 to the original. I can get a picture if someone needs one to help explain.

Does the new script solve this? Does the offset change that part of the sculpt? Or will I need to rebuild the sclpt with the seam in mind as I shape, please?

The only way to move the seam without rebuilding the object is to edit the UV map. Identify the edge you want and mark it as a seam on the mesh, then move the entire UV map sideways until that edge is at the edge of the image area. Then move the section of the UV map that is outside the image area to the other side to make the UV map square again.

The new scripts mark the seams, so you can display them on the mesh while editing your sculpties to avoid this in future.

I've got an issue for you, Domino. For some reason when I try to export a bench I made out of a cylinder mesh, almost every vertex gets shifted around so it's a spikey mess in a half cylinder shape.

http://feynt.kicks-ass.net/Club%20Bench.blend

I tried making a plain sphere though in the same scene and it renders just fine. >P

That's odd. I've no idea what would have caused that. If you apply multires before doing the bake, it works correctly. Just reimport the map to get multires back.

I'd redo the closing of the cylinder, so that each LOD level is closed. At the moment gaps appear on multires 1 which are due to aligning LOD1 vertex to a higher LOD vertex.

The magnet icon on the toolbar enables snap to vertex rather than snap to grid when ctrl is held, it's useful for doing that type of closed edge.

Thanks. Rather than snapping though I just scaled to 0 any verts I wanted to overlap.

Let me ask a question or three about the new features in the git/rc version then ..


Oblongs:

1. Are multires levels 2 and 3 supported with oblongs? Do they need to be applied to the mesh before baking? (Do any modifiers need to be applied before baking?)


2. Can you clarify the workflow with oblongs ?

* define a number of faces other than 8 x 8 in the sculpt mesh options. Assuming multires works (see 1), you'd choose say "32 x 2" for 128 x 8 faces or "4 x 16" for 16 x 64 faces
* when ready to bake, do you add a similarly sized bake map to the UV editor - or do you just go to "Bake Sculpties"? In this example, would you add a map with dimensions 256 x 16 (for 128 x 8 faces) or 32 x 128 (for 16 x 64 faces)? I seem to get funny results when I just bake from the menu.
* are the oblong sculpt maps instantly being resized to 64 x 64 during the bake? (I've seen it do that after creating an oblong sculpt map manually first)
* re. "funny results" - how do you know your oblong sculpt map is being respected? After all, you may be looking at a normal 64 x 64 map with faces/resolution in the wrong place but thinking that you've been sloppy


3. Several "competing" spreadsheet proposals with various oblong dimensions and their LOD calculations have been attached to http://jira.secondlife.com/browse/VWR-9384.. which one reflects the state of things in the SL viewer, and which one do you use in your scripts?


3a. What is the maximum supported number of faces on X and Y? It seems to clamp to 32 on either axis - this would translate to 128 faces with multires level 3 ("levels: 2" in the menu)

______________

Multires:

The labeling of the multires option has changed to read
"Multires Levels: 0" = no multires, 1 = multires level 2, 2 = level 3 ? I find that a little confusing.. after all, it does not say "add 2 levels to arrive at level 3". I believe someone asked you to change it but it's not intuitive this way IMHO.



EDIT - NEW Q.

How do you know you've been using the wrong scripts? -- By looking through your file path settings, *especially* when you upgrade your blender. It seems that subfolders of the designated scripts file path are not being parsed after all.. neither inside /.blender/scripts/.. nor in a separate script folder. I'd recommend to use a separate scripts path and not use subfolders.

le sigh.

The quick answer is yes. The long answer is it depends. If you specify 32 x 32 faces then multires isn't supported on square maps either. As the rules for what is and isn't supported are fairly complex to apply, I decided to limit the scripts to only create sizes that can be baked to a supported sculpt map size. This is slightly higher than the maximum sizes that the SL viewer can support. One of my reasons for this is that it allows higher detail maps to be baked for external rendering. I know Qarl Linden has been rendering sims in Maya and I'm watching Blender 2.50 development as a possible platform for a more content creation orientated client.

If you want to keep within the SL client limits, then the maximum number of faces is 1024. The 1.21 client will only support map sizes of 4096 pixels or greater. The changes made by Qarl in response to vwr-9384 are currently in the maint-viewer-11 development branch, that will add support for sizes under 4096 pixels.

So for example:

11 x 23 with 1 multires is supported on a 64 x 128 map in the 1.21 client
4 x 8 with 2 multires is supported on a 32 x 64 map in maint-viewer-11

When maint-viewer-11 is integrated into one of the official downloads, then I'll be documenting what works in more detail. Basically it's the Domino table from vwr-9384 with a 4 x 9 for LOD0 instead of 4 x 8. My scripts will still use 4 x 8 as it's better for modeling, and I want people to be able to test them for when that issue is raised as a new jira.



Not easily in a short forum post.



OK so far



The correct size map should be created and assigned to the "sculptie" uv layer when you create the sculptie. You don't need to do this manually unless you do something like starting with a 4 x 8 with 0 multires then adding 2 levels of subsurf. This would need a bigger image than the one created by the scripts. So you'd create a 32 x 64 and assign it (on multires 1) to the "sculptie" uv layer.

If you are getting funny results, then finding a simple way to repeat the problem or sending me the blend file, so I can investigate it is the best approach.






Maybe you are seeing the "smart" part of the sculptie generator in action. If you request odd sizes, such as 5 x 7, then it calculates the power of two size up ( 8 x 8 ) for the map size. Then the odd number of faces is aligned with where the real 8 x 8 faces are so you get some odd faces covering two uv faces of the 8 x 8 grid. I did warn you it wasn't easy to explain

If you turn off "Clean LODs" you still get the sculptie map size for the power of two size up, but the alignment of faces is turned off so you get an even spaced 5 x 7 uv layout.




I think I mostly covered these above, but to summarise:

There is no maximum number of faces on X and Y, but a combined maximum of (X * Y) <=1024. Check you are on the latest git / rc if the input stops at 32.

The scripts are based off the Domino table of course



I'm not happy with that label either, but the numbering is right. It's the number of levels added, not the number you end up at. So the 8x8 faces is level 1, plus 2 gives 3. With it representing either subsurf or multires, something like "Add Levels" seems best, but that doesn't answer the question of what is being added.... Maybe I should change the "Use Subsurf" button to a "Subsurf / Multires" choice and position it above the "Add Levels"... it's sorta getting there... Thanks for reminding me to think about this

Hi Domino -
Is there any particular reason why i can no longer compress a set of vertices to '0' in all three dimensions and have it upload at a true 0? I am now seeing a thin strip along supposedly '0' portions of my sculpts and I'm not really sure what's wrong - IE: whether i'm using the right options while uploading, since there are so many additional options that come with the RC plugins.

If it's a difference between versions of my scripts then it might be because the speedup from using the bounding box was removed in a recent one. It gave baking inaccuracy in some cases. So I'd try the latest and see if that sorts it out.

Otherwise, there was a change in the viewer at 1.19 which fixed a bug that had the side effect of not allowing a true 0.0, 0.0, 0.0 baking position http://jira.secondlife.com/browse/VWR-2550 - this is an effect of having an even number ( 256 ) of vertex positions so is expected behaviour.

Feature requests:

A means of applying specific ratio values to RGB values... eg: so I can specify *numerically* that I want to scale the normalized axes at 1:1:0.5 ..etc.
(not so important because this can be done in transform properties dialog... but would be useful for avoiding the need to alter the object itself)

Better naming continuity with export lsl option:
eg: so that:
object 'Sphere' produces Sphere.tga and Sphere.lsl
object 'Sphere.001' produces Sphere.001.tga and Sphere.001.lsl
Currently:
object 'Sphere' and 'Sphere.001' *both* produce Sphere_map.tga
(when cloning with shift-d ...actually this is avoidable by altering my technique or simply renaming the map... so maybe disregard this as a request and take it just as a note for possible improvement if any simple opportunity to do so exists.)

My preference would also be for the image to always be the same as the object and not automatically have _map added to it. (though i do usually add _SCULPT or _RGB to them myself.. so I can see the need to differentiate a sculptie image in its name.)
This is more of a continuity issue than a problem.

Length of object/filenames is a problem too.... maybe some kind of checking/warning is needed.

A 'protect map' option which is totally alpha, without any coloured pixels.


This is now an almost completely essential set of scripts for me, so please excuse me if my input sounds a bit demanding. :] I could go back to doing this the old way.. but your export scripts in particular speed up the workflow enormously while still allowing us to build totally from scratch if we choose. Awesome.

Can you give me a example of how this would be used? This functionality is there (I tend to refer to it as sizing spheres) as the normalization range is calculated across all selected prims. This is not ideal I know, but it seemed the best option to cover the widest range of uses.

One idea that has been tickling my mind is having the rgb range as an option. So 0 to 255 would be the default, but any values could be entered. So for the 1:1:0.5 option, you'd just change the B end value to 127. This way it's also useful for baking to a 1 to 255 range to give sculpties a vertex row at the mesh center (not prim center).



I think this is expected behaviour. When better linkset support is added, having multiple prims coming from the same map is a good thing to have.



If I don't add anything to the sculptie map filename, then I have to add to the texture filename to differentiate the two. When sculpties first came in, there was some confusion caused by the various ways of referring to the sculptie map, as an image, a texture etc. So I started trying to always refer to them as sculptie maps to help cut through that confusion.

So a full textured sculptie export would be:

Sphere.lsl
Sphere.tga
Sphere_map.tga

I'm not sure any change to that would be beneficial.



This is a Blender limitation which I'm hoping will go away with 2.50

I avoid long filenames so haven't seen any problems. If it's possible to get broken results (ie bad texture names in the lsl) then it is a bug. I'll need to address it before the rc goes to 1.0



No problem. I'll add that when I rework the ui to tidy up that "Multires Levels" issue Yuu raised. I'll change the button to a list selection with "None", "Preview" and "Clear" as the options. I'm hoping I can improve the math for the preview to reduce the depth distortion.



Even if they weren't essential, there's nothing to excuse. Your points here have either raised points I need to cover in the user manual, or will lead to script improvements.



I really should start collecting quotes to add to the website

Precisely like that.
Most often I use it to precision fit a sculptie to a megaprim thats nearly, but not quite the right size.
But I have also used it to make sword blades that were 0.005m thick... and micro loops for jewelery etc.
Or simply to increase the distance at which LOD munches a worn or otherwise phantom object.

Agreed, they need to be differentiated with the shortest name possible.
I guess really I was pointing out that cloning objects leads to duplicate references to the same map... so maybe it would be useful to accommodate blenders habit of appending names with .00n in the naming of the image.... or just strike off the map reference from any cloned object.

<brainfart>
BTW The naming scheme I have evolved toward so far (for square sculpts) is along the lines of:
ObjectName.001_RGB64 [64x64 with no alpha]
ObjectName.001_RGBA64 [64x64 with alpha]
or
ObjectName.001.RGBA64 [etc, often periods fit it in the image name field better]
and
ObjectName.001_TEX [texture]
ObjectName.001_AO [Ambient occlusion - usually ends up as a _TEX anyway]
ObjectName.001_UV [UV grid - again intermediary and often ends up as _TEX]
etc
But of course this gets longer and unwieldy with ratio'd sculpts.
I haven't thought about those much, but i suspect i'll go for a special meaning char like:
ObjectName.001_RGB8^128
or get abstract with somehting like
ObjectName.001_RGB1=16 [1:16 ratio]
or
ObjectName.001_RGB1-16
...or much more likely: just leave it at _RGB and _RGBA and omit any size info completely... and possibly add it on again outside blender just prior import to SL... IF i really feel like differentiating some based on size of RGB image. (which I often do)
</brainfart>

Nice.


:]