Blender Sculptie Importer - Attached

I'd use the normal "Unwrap" which does a LSCM unwrap on the initial plane. Subdividing also subdivides the UV map, so you don't need to unwrap again. The reason I added the new script yesterday is that I'm planning a video on understanding sculpties and I wanted to explain it by showing how the 32 x 32 plane becomes the other shapes.

Try it like this:

1) Add - Mesh - Plane
2) Add a UV Image Editor window
3) Press U to unwrap and pick "Unwrap"
4) Subdivide the plane 3 times
5) Enable multires and set the type to "Simple Subdiv"
6) Add two multires levels.

You should now have a plane sculptie that is identical to one added with "Add - Mesh - Sculpt Mesh, plane, 8 X Faces, 8 Y Faces & 2 Multires (the default).

What a coincidence... Guess, what i am running after at the moment ... ok, then i will wait for your video now. nevertheless...

After following your advice (tried 2 times to be sure, i did it all right), i end up with a sculpt map which shows black pixels. (see attachment) Baking with "Fill holes" seems to cure the effect, but the resulting sculptie is a bit "unclean". no comparison to Sculpt->Mesh->plane .... i have the feeling, there is something wrong. I would not expect to get precision problems here... You find me a bit helpless

This actually highlights the main difference in our approaches. With prim.blender you have added an SL style interface on top of Blender, whereas I'm aiming at putting the Blender interface over SL primitives.

As each menu hook needs to be in a separate file, I have to go the many scripts with an installation route.

Personally I think it's great that there are two solutions for Blender, each with unique approaches that will attract different people.

Might be awhile.. The video is the test for the new script, so until I get that working.....



It might even be a Blender bug, this behaviour seems very odd. If you get the black holes with this method, the quick way to fix is to enable "Snap to Pixels" in the UV menu. Select all faces on the UV Map, G to grab them then left click to set positions. They don't appear to move, but the bake now works correctly. I applied multires to do this, needs testing if the same actions on multires level 1 works or not.

Yes, that works. After applying "snap to pixels", i can make a precise sculptie map now...
I wonder, if it makes sense to let the sculptie baker make a snap to pixels before baking... Oh, if i only would be more knowing about scripting

Ok, now i know more ...

the following snippet in the sculptie baker has already been my target once
i added the r,g,b variables only for pretty print purposes here. The major change
is in the calculation of the pixel coordinates, see below:

for i in t:
r, g, b = scale.normalise( f.verts[ i ].co )
r = round( r * 255.0 ) / 255.0
g = round( g * 255.0 ) / 255.0
b = round( b * 255.0 ) / 255.0

# The following rounding cures the problem:
u = round(f.uv[ i ][0] * sculptimage.size[0])
v = round(f.uv[ i ][1] * sculptimage.size[1])
# That was easy and it makes sense to me ...

nf.append( pixel( u, v, r, g, b ) )

I hope, that passes your QA...
Did i mention, that i never give up ?

That's reasonable.

I like Gaia's "automatic install" .blend script idea. Not sure how easy that can be done on systems that require root, but it's not *that* hard to conceive some form of prepackaged installer of your scripts.

I've pushed this change to the git repository along with another one that corrects the centering of flat planes. I've a few more tests to do and if all goes well the release scripts will be updated later today.

Edit: I've updated the release zip. The main scripts package now has a new URL:
http://www.dominodesigns.info/downloads/second_life/blender_scripts.zip

The old URL will still work and get the latest scripts so tutorials don't need updating.

The technical bit:

What this patch fixes is the culling of (triangular) faces that were less than one pixel. This means that even very detailed meshes will bake. Where a UV pixel contains many faces, the last to be baked will overwrite the earlier faces. With hindsight, preventing this behaviour was probably a bad design decision on my part.

In the case of many faces that close together, there is unlikely to be a noticable difference in which vertex is treated as the right one to bake the position. Allowing it makes texturing much easier as you can now add many more multires and subsurf levels without corrupting the sculptie bake. I prefer this behaviour as it's generally quicker to model detail than to paint it on a texture

New scripts uploaded featuring a new sculptie prim type! Well sort of

http://www.dominodesigns.info/downloads/second_life/blender_scripts.zip

There's now a 5th option on Add - Mesh - Sculpt Mesh for a "Hemi"



This half sphere shape is based on a plane sculptie with the outer edge of the plane as the circumference of the hemi. I added it to give an easier starting point than the plane for some types of models.

You can turn it into a full sphere by scaling the UV Map to 0.5 in Y and moving the result up to the top of the UV map. Add a mirror modifier on Z & V and you have a sphere. A sphere made from a hemi has a different topology than a normal sphere and might make a easier starting point for shapes that need more vertices on the circumference than a normal sphere. Remember to create with Y Faces = 4 rather than 8 if you are making a sphere, the other 4 are added by the mirror.

Edit: Reuploaded with corrected hemi generation ( fixes the blast from the past of inside out sculpties )

I'll be expanding the documentation and adding tutorials as time goes by. All suggestions welcomed

May I make one small request: would you consider adding "Second_Life_Sculpt_" or "Sculpty_" to the front of the file name, in the future? The current name, "blender_scripts.zip", doesn't say enough about what's in the ZIP.

Some mention of Second Life and/or Sculpty in the filename would be helpful.

This is one of those requests that seems simple but isn't. From a development point of view, having one repository that all my work on any Blender script goes into is a lot easier to manage. It saves me from having to ponder difficult questions like "does the 'EAC from View' unwrap script belong in the sculptie_scripts. zip or an unwrapper_scripts.zip?"

So the reason the zip is called blender_scripts.zip is because that is the most accurate long term name for it. It gives me a single publishing path for my Blender scripts and will save me a lot of time in administration work keeping track of things. Only difficult question then is "is this script ready to go in the release zip?"

You could always use the development release as you can name the destination directory anything you like when you clone the master . Just change the "blender_scripts" to "second_life_blender_scripts" at the end of the command.

OK, I can live with that, with gratitude. Thanks!

do i need to do something with python to get these scripts to work by chance cuz i dont have the script file im suppose to install the export tool to and i also tried what was seggested on the web site with

import Blender

print Blender.Get('scriptsdir')

and hit alt-p but nothing happened thanks

I've discovered a little bug in how sculpty baking functions.

While not one with a severe impact for single, sculpted shapes, the code used to generate "normalised" behavior moves the center of the baked sculpty away from the Blender object center.


This is of particular note in your code to set the position of multiple sculpties. Because the created map is "off center", one can no longer rely on the object location data.



I have fixed this in the latest release of Prim.Blender, by extending the bounding box used to create the sculpty in all directions, from the Blender center of the object.



A corollary to this is LOD is more "efficient" when baking using the current method, but at the cost of having control over the center of the object.

Because this can be easily fixed by "centering" the object, I have left this choice to the user.

Bug? Design decision



My code for multiple sculpties? I wasn't aware I'd released any. As far as I know it's all in my local "linkset" branch

I've not decided the best way to do this yet. The cleanest would be to update the center of the object after baking, though I've avoided any non-user initiated changes to the mesh. So, I'm not sure whether changing the object centre should be done, or whether to just store an offset during baking to use when generating the location LSL code.



Is this any different to turning normalise off?



It's not the LOD that's affected but the quantisation step when turning the mesh X, Y & Z positions into the 256 available color steps. Preserving the center increases the size of available steps and reduces the amount available to the mesh.

Consider an object 0.0 to 1.0 on X, to maintain the center the range would be treated as -1.0 to 1.0 (so 0.0 is center). Each red pixel step on the sculptie map now moves twice the distance, and only half the available range is used for the 0.0 to 1.0 verts.



Yep. Can either manually center or can turn off normalise. I think it's more a documentation issue than a bug.

Normalised = maximum sculptie detail, location will change unless center is correct (use "center new" to set), sculptie will be scaled to 1.0, 1.0, 1.0

No normalised = preserve sculptie relative scale, center (will need setting manually before baking for optimal results) and location. Sculptie map step size will be increased so mesh position steps not as fine as with a normalised bake.

I choose to call it a "bug" because, when looking at the print output you are using for llSetPrimitiveParams, the logic you have used deviates from this point (you appear to be using the Blender center for the prim).

Further, I had attempted to use "normalise" both on and off in the virgin code before mentioning this. Both appeared to give me an off-center result. Though it is possible there have been changes between yours and mine since I forked.


I am aware of the quantization step you are referring to. I call it LOD, because the constraints adversely affect detail through binding the results (this is how it was brought to my attention, leading to my explaining exactly this principle to camilla before the above post). You describe the input, I describe the output.

Of course, this is a minor point.



This is not backed up by any documentation in the tool, so I wanted to make sure you were aware of this. If you are, that is all.

I thought I'd written the "normalise" off to center as well. It seems I didn't. I've just committed a change to the git repository to add a centering option. It made sense to make it separate so that keeping the center and keeping the relative scale are independent.

I still need to figure out how to update the object's center from Python so the default "Keep Center" off option updates the mesh. Now it's user controllable, it makes sense to update rather than store an offset

Edit: More changes in GIT. Now updates mesh center. Doing this for the scale also makes sense, so going to work on that before updating the main release scripts. Anyone wanting to upgrade early for the new features (Keep Center is great for doors!) can get the development release from

everytime i go to upoload a sculpty its like there seems to be a some kinda invivible box there if anyone can point me in the right direction or maybe emial me to figure this out at xerokool1981@yahoocome thank sss thx

I'm going to guess that you mean on the upload preview window. In that case, it's likely that the sculptie is inside out. Flipping the image on X should sort it out (or mirror the UV map on X to correct it in Blender).

srry for the messed up post i was tired last night

anyhow i can upload the sculpt just fine but when i get it in world it seems as if theres some invisible box around the sculpt not letting my avi walk up and actually bump into the sculpt but instead gets stopped by something invisible surrounding the sculpt

also i am very new to blender so the stuff u suggested im not sure how to do ,but i do love your plug in and tutorials they are very helpful and you are very appreciated thank you very much

The physics engine of Second Life doesn't use the sculptie shape, but a torus scaled to the X, Y, Z size of the sculptie. If you baked with "Normalise" enabled and "Keep Center" disabled, you shouldn't get any invisible barrier and may even be able to walk through corners of the sculptie.

In cases where the collision shape is an issue and you can't fix it in the bake, the only option is to make the sculptie phantom and use a normal prim or two to act as the collision mesh.

ok thank you very much for the help gonna mess with it and see what i get

i cant seem to find the keep center bit u said to disable i found the normalize of course though

Keep Center is only an option in the development version at the moment. The current release always has "Keep Center"disabled so if you don't have the option, don't worry