Blender Sculptie Importer - Attached

Doable, yes. Valuable less so. The valuable way to fix this is to merge the vertice at the poles so there's only a single vertex there. I need to look a little closer at the exact UV map layout required to do this. It's been on my todo list for awhile, but as it only affects texturing and there are multiple ways around it, it's just not very high on it

Sorry for bothering again. I am currently doing some documentation, so i stumble over such sort of things ... Sometimes people hate me for that

So... I just detected, that specifying a Multires level of "2" in the sculptie creation menu results in a Multires range from 1-3 in blender's multires tab. Although it does not matter very much, wouldn't making this consistent be good for understanding what goes on ?

I created a patched version of add_mesh_sculpt_mesh.py, where i basically modified 3 lines. Sorry, i tried to append the file to this note, but the forum reports "unexpected errors" But the modifications are obvious, i guess ...

OLD: settings = {'x_faces':8,'y_faces':8,'type':1,'multires':2}
NEW: settings = {'x_faces':8,'y_faces':8,'type':1,'multires':3}
...
OLD: block.append (( "Multires Levels", multires_levels, 0, 255 ))
NEW: block.append (( "Multires Levels", multires_levels, 1, 256 ))
...
OLD: ob = new_sculptie( sculpt_type.val, faces_x.val, faces_y.val, multires_levels.val )
NEW: ob = new_sculptie( sculpt_type.val, faces_x.val, faces_y.val, multires_levels.val -1 )

If this patch (or something equivalent) would find its way into the scripts, we could just tell, that the Multires level during creation directly corresponds to the Multires level in blender. and we do not have to explain, that blender starts counting from 1 while the scripts start counting from 0 ?!?

The 2 is the number of multires levels to add, not the final number of levels. When you enable multires the current mesh becomes level 1, so adding 2 levels takes you to level 3.

I'll have a think whether the correct behaviour is

0 - disable multires,
1 - enable multires, don't add any levels
2+ enable multires and add levels to take to this amount

But as the 1 case is so unlikely, I think I prefer the current method.

Isn't the 1-case equivalent to "no Multires at all" from the effect on the object ? I think, this 1-case somehow even triggered this dispute

Maybe things get much clearer when shifting the viewpoint completely:
What about renaming "Multires Level" to "Base Resolution" or simply "Vertex Count", saying that this is the mapping:

0 : 256 Vertices
1 : 512 Vertices
2 : 1024 Vertices (default)
...
oh, while we are at it.. did you ever try to set the value to 255 ? )))))
I would set the maximum value to 10 (that corresponds to 130000 vertices)

Then "silently" enable Multires for objects with >= 512 vertices

I mean, this IS the current behaviour anyways, but it could be explained very easy. Then,
as an add on in the documentation:

"Note for experts: When you choose to create your Sculpt-mesh with 512 vertices or above, you get the additional benefit of Multires..."

So, newbies just understand immediatley "i can controll the number of vertices" while experts understand "multires is automatic enabled when enough vertices are available"

An alternative would be to completely separate multires and vertex count...
But although cleaner, i have the feeling, that is a bad idea...

hmm... "control the vertex count" ??? I have to explain that "this is only during sculpting in blender... the final sculptie baker will recreate 1024 vertices in any case... ok it is the nature of the sculptmap, that forces this behaviour" well... ummm just puzzled by now. I need a break....

What do you think about the idea of renaming the button ?

I don't like it. The name already matches the Blender feature it configures and the expected result from adding X levels. Base resolution of the mesh is really the Faces settings, and multires adds to that. I can't see a need to change it.

New scripts are available from http://www.dominodesigns.info/downloads/second_life/import_sculptie_svn.zip

This is a major refactoring of the export_lsl script, and it now supports exporting textures.

Models need two UV maps for this to work. One called "sculptie" and one called "UVTex". The image assigned to the "UVTex" is used to texture the sculptie in Second Life.

Quick guide:
Select sculptie mesh in blender
File - Export - Second Life LSL, choose a directory to save in.
Check contents of save directory
Then in SL upload the two .tga files
Drop both into a new box prim
Create new script in box
Paste contents of .lsl file over it and save.
Delete contents of new sculptie.
Take a master copy
Have fun

If there is no UVTex layer, then simplified LSL is saved to just do the sculptie shape from the single .tga file.

Edit: export_lsl now at 0.03 (bug fix in lsl output, was missing quote on texture name) if you don't remember this note download again

uhhhh... ok, i had to reset my brain completely (again). And after neglecting Multires in first place (setting it to 0) , now i (hopefully) can see the mechanics in a correct way. So i ended in the following ruleset:

It helps to set Multires to "0" for a moment, then everything starts to make sense (that is what i learned from your statement about "the faces settings define the resolution, and Multires adds to that":


1.) The number of x- and y- faces defines what it says. That means, if you set 8 faces in X and 8 faces in Y, your mesh will get exactly 8*8 = 64 faces. in terms of vertices:
A plane will get 9*9 vertices = 81 vertices.
A cylinder will get 8*9 vertices (stitching on one edge) = 72 vertices.
A sphere will get 8*9 vertices (stitching on one edge) = 72 vertices
A torus will get 8*8 vertices (stitching on both edges) = 64 vertices.

2.) changing the numbers on x or y creates always x*y faces similar to what was explained in 1.) above.

3.) As a consequence of this, the only mesh type, that accepts (1*1) faces, should be the plane. In fact all other mesh types produce a python error when trying to create a 1*1 face object. As another consequence, trying to create anything with 2*2 faces must result in a flat structure. indeed i could verify that. So true 3D objects start to appear when creating (3*2) face objects. 2*3 objects don't work (are flat), thats again because of stitching i
think)

Now Multires comes into play:

4.) Setting Multires to "0" is equivalent with "no multires" and consequently has no effect on the created sculpt-mesh.

5.) Setting Multires to "1" is equivalent with 2 levels of Detail. Since each additional level of detail doubles the number of faces in x AND in y, The sculpt-mesh now gets 4 times the number of faces, compared to no Multires enabled. A plane now gets 16*16 = 4 * (8* faces, or 17*17 vertices.

6.) Setting Multires to "2" is equivalent with 3 levels of Detail. Again a duplication of faces on x and y result in 4 times more faces than before. Now a plane got 32*32 faces, or 33*33 vertices.

It happens, that the default settings (8 faces on X, 8 faces on Y, plus Multires ="2" , which is equivalent to multires level 3) are exactly representing the final values used in world for Second life sculpties.

So... Is that now a basis of knowledge from where on i can safely continue, or do i still have something wrong here ?

I think you've got it

I'll have a think about the small holes as poles of spheres too. If I do the right thing and convert to a single vertex, it's actually the wrong thing due to multires. Well more like due to the quirk of the pole implementation of sculpties. The multires LODs would be wrong as the mesh topology changes with the sphere's LOD in Second Life and doesn't in Blender. This is why the smallest sculptie LOD ( 6 x 6 ) isn't implemented too.

Edit: new scripts just uploaded, small circles for poles and saner ranges on field inputs.

I've not tried texture baking so let me know if the circles need to be a different size. You can alter them in the import script code under the default_sculptie function for the sphere.

I just tried today's newest scripts (as of Sunday, June 29, 200. I noticed that "Normalise" is engaged by default. I wonder if you meant to do that. I'm not sure that's the best choice for default behavior, if I understand you correctly, because it means that I might sacrifice detail just to keep the model in the same proportions. So now I must always deactivate "Normalise". Judging from what you've taught me, in this thread, about scale and proportion issues with sculpties, I am guessing you did not mean to normalise, by default.

BTW, I just discovered, today, the video tutorial Gaia worked on, about how to create a texture map for models made with your sculpty scripts in blender. I found it very, very helpful... and I also noticed the newer script version, so I came to get it, and found an even newer version. Wow, cool!

You keep us running. Your new name conventions make parts of our video tutorials wrong or at least confusing, so we will start the next update round now. We have to correct some parts anyways, so we just can make the videos completely upto date

I understand, that your name conventions "sculptie" and "UVTex" just trigger the creation of the additional script lines... So i conclude, we have to redo our wording in the texturizing video:

What was "UVTex" before is "sculptie" now
What was "UVTex.001" before, is "UVTex" now

So we can skip the part where we say "rename your new texture to 'surfaceTexture' ..." and instead of using "surfaceTexture" we just keep the name "UVTex" for simplicity and consistency with your scripts... There are no other changes to be made in our videos regarding the UV textures. Is that Correct?

So we can now say: "After you have baked the surface texture, go to "File - Export - Second Life LSL" and specify an export directory. After saving, you find the sculptie map plus the surface texture plus an LSL script in the export-directory. No more need to save the image out of the UV/Image editor...

Sorry about that. I do keep saying the reason I don't do proper tutorials is that the scripts are under development still and may change.

They are both going from "anything" to the specific UV layer names now. It made the most sense for future planning. When other prims are supported, UVTex is the texture for face 0, UVTex.001 will be face 1, etc. It seemed a major gain in usability to have an easy way to identify which surface texture is which.

If you add a new sculpt mesh, the default UV layer name is now "sculptie". When you add a UV Layer for texturing it will automatically be named "UVTex", so for new sculpties, the layer names should be correct without renaming. The renaming is just for older content to make them compatible with the LSL export.

As people have been blogging about the scripts in various languages that I don't speak, it's tough for me to know what conventions people have developed. I do my best to keep changes that make things obsolete to a minimum, but even my own videos have a lot of outdated info now.

But given the choice between making things easier for the user or keeping existing tutorials current, I'll pick the user every time. It's when the scripts can't make it any easier that it's time to do the final tutorials



Yep. You might want to mention renaming the sculptie before baking too, this will give better names for the .lsl and sculptie map .tga

As with any brand new feature in the scripts, it might change tomorrow though. I think I've planned fairly well for expanding the export_lsl script, but until I get into the details I won't know for sure whether I allowed for everything.

I've had no feedback on the latest versions yet, though I don't forsee any major problems that will change the Blender user interface to them, though the SL side may change if I add linkset support to the lsl export.

I still think, it is worthwhile to tell the world about your scripts and advertise them by creating good understandable tutorials. I don't care too much, that they might get outdated sooner or later, since we meanwhile got a good and efficient infrastructure for patching the tutorials. And i can now create Sculptie helmets while i'm sleeping

I am currently reworking our video tutorials. But i noticed something in your last note, that puzzles me: In our video tutorial about texturing, we (until now) explain, how to create a simple intermediate UV-map (projection map). Then use this projection map to create the initial surface texture image and then use the sculptie UV-map to render the final sculptie texture by telling blender to use the intermediate UV-projection map as input for the final bake. We never let the intermediate projection UV-texture out of the blender file, only the baked results get imported to SL and that works perfectly...

How does that fit into your new concept ?

After having read your note several times now, i start to wonder, if we are making things in the right way. Yes it works, but maybe the procedure is ... non standard ?
is there a better/more standard way to do it ? Why would i want to create a second UV-texture and a third one and even more UV-textures for one sculptie ? Isn't the first UV texture (now called "sculptie" the one and only texture, that defines, how sculptie surface texture images have to be mapped to the sculptie's surface ?

Or is the secnd UV texture simply a copy of the first one and serves only as placeholder so that your scripts can export the texture- tga file associated to the UV texture?
In that case would we then need to create 2 extra textures for our video tutorial about texturing?

- One which hosts the final texture image
- and another one for the intermediate projection-UV map mentioned above ?

I again don't see how to proceed.

thanks for any clarification and advice.

Nicely. the projection map is what I called ref_something, it could be proj_something or anything. For a sculptie there are two UV maps, the "sculptie" one and the single texture "UVTex".



For photosourcing textures, your way is fine. The reason I have seperated out the sculptie uv map and the texturing one is so that the texturing one can be scaled and rotated to match it's Second Life options. If I do a car wheel from a cylinder, then I might only want to bake part of the tread. Scaling the "UVTex" on x by 8 would give 8 repeats. This isn't implemented yet, but these are the kind of things I'm laying the groundwork for now.



- and one for the sculptie map

PS: new export_lsl script just uploaded to fix the ALL_FACES issue in the LSL.

Hi, Domino;

I just downloaded your newest script versions.
the following use case produces a reproducible blender crash:

1.) start blender
2.) load the factory settings
3.) remove the default object
4.) SPACE -> Add -> Mesh -> Sculpt Mesh (mesh type 1)
5.) UV texture -> New ===> BLENDER CRASH

When i go to edit mode before i perform step 5, everything is working though.
I also checked for other object types, but i could create UV textures for them with no problems. only sculpt meshes suffer from this problem.

I checked that on Windows-XP with blender 2.46

BTW: Thanks so much for your ongoing help and commenting/answering my longuish texts and questions

Just to be sure, i understood this:

1.) The first UV map named "sculptie" hosts the standard UV map (32*32 squares, ready for export to SL as sculptie map) This UV map is generated, when a new Sculpt-Mesh is created. nothing differnet from before except the new name.

2.) the secnd UV map named UVTex is a placeholder for a surface texture. this map will be created manually, if needed. It is typically a copy of the "sculptie" UV map, later modified for special texturing issues, but finally it holds a 32*32 squared UV texture which fits exactly to the "sculptie" UV map. The sole purpose of this UV map is to allow special treatment for texturing, that would otherwise destroy the "sculptie" UV map if performed on that one.
The name "UVTex" is a name convention. So if the LSL exporter finds an UV map with this name, it assumes, that is the texture for the sculptie and exports an associated .tga file wich contains the ready baked surface texture.

3.) Any further UV map with name convention "UVTex.nnn" will be treated the same as UVTex from the LSL exporter.

4.) All other UV maps with different names will be completely ignored from the scripts.

as a consequence for our texturing video:

1.) We will create a second texture and rename it e.g. to "projectionTex" as before
2.) We will prepare the projectionTex as allready shown in the vid
3.) We copy (? How is that done?) the "sculptie" texture to UVTex
4.) We set UVTex to active/rendering texture
5.) We bake the surface texture
6.) We export -> second life LSL

done!

is this correct ? OMG... sorry for not stopping to ask, but i start getting to my limits and need a bit more of help

I'd do it as:

1.) Copy the active "sculptie" UV Layer to "UVTex" by adding a new UV Layer.
2.) Copy "UVTex" to "UVTex.001"
3.) Rename "UVTex.001" to "projectionTex"
4.) Prepare "projectionTex"
5.) Set UVTex to rendering texture and add a new image ( on multires level 1 )
6.) Bake the surface texture
7.) Export - Second Life LSL

Updated the export_lsl script to 0.05, this now deletes the images and script from the final sculpties prim. Also fixes "Untitled" image bug.

I've also uploaded a sample .blend file with a mushroom sculptie. The sculptie (ughh LOD!) and lighting were only quickly done as I wanted to focus on the materials and the UV layer settings. I've used nodes to setup a mix of 4 different materials based on the v height of the meshes UV grid. The colour ramp nodes control the mix. I've packed the textures so it's ready to export to LSL. Pull it apart and free free to ask if things aren't clear.

http://dominodesigns.info/downloads/blender/mushroom.zip

A bit of an interesting observation after porting the code:

These scripts are so accurate, that copies of a sculpty that are transformed, rotated, or scaled generate *exactly* the same image file (by md5sum).


That's pretty freaking impressive, and also says good things about Blender's float math.


The follow-on observation is this property can be used for image culling, when it comes time to import several sculpties with common maps.

Thoughts?

Domino, with respect to the black triangles issue for baking textures, might it be possible to make spheres like a cylinder, only don't overlap their poles? I think the issue might be that either triangle culling might be occurring (doubtful) or that the overlapping vertices is causing Blender to assume that one triangle in every quad is inverted, facing inward, when it shouldn't be.

The scripts do use a cylinder shape for sphere. I modified the add - mesh - sculpt mesh to leave the poles slightly open a couple of days ago. I tend to add a subsurf modifier before baking textures and I don't get the black triangles (see mushroom a few posts up). If you use snap to grid on the poles though, you might end up closing them again during modelling.

Also imported sculpties still have closed poles, it'd be pretty complex to open those as it would depend on the surrounding vertices and getting it wrong could add shadow artifacts.

I'm not sure how useful it would be to cull images. It would at least need to be optional so that multiple imports of the same sculptie could be individually edited and baked to seperate sculpties. There are cases where update one, update all is the right behaviour and cases where it isn't. If the user has gone to the trouble of specifying multiple sculptie maps for the same shape, there's probably a reason why. Maybe it's possible to check the "File - Compress File" setting in Blender and use it to decide whether to remove duplicates or not.

Hey, cool. I just tried texturing with a new sculpt-mesh. No texturizing artefacts at the poles any more. But i will keep the hint about the black triangles in our video tutorial, because as you pointed out in your last note, snap to grid could place the "pole vertices" back into the same position and boom, triangles are back. So it is good to know the workaround anyways.
BTW i got aware of your edit only after i read your last note...

Sounds about right.

I bring it up because I have a workflow going that saves out all the sculpty maps automatically, including the primitive params, to .prims format.

Automatic culling would be exceptionally handy in this case, because it'd cut down on the amount of postprocessing required in primitive params, or counterpoint, the number (and cost) of texture uploads.

For exports I'd do the culling before baking the sculptie maps. The image name in Blender should be enough to identify unique instances. If someone builds a garden with 20 sculptie roses, they should all be linked to the single sculptie_rose.tga image. It seems overkill to bake that rose 20 times just to make sure it is unique.

The user should go, ok I've edited this rose's mesh but want to keep the others as they were. They add a new image to the "sculptie" UV Layer or just clear the existing link to the "sculptie_rose.tga" image. This would leave the other 19 roses pointing at the original image and a separate image for the edited one.

The export routine would see 20 sculpties with 2 unique images, save those two and call it done.

I took the route of if the sculptie map image already exists, then just save it when you export. You never know how that map came to be. I've got sculpties that are rigged with an armature and a 200 frame cloth sim, which I bake from later frames chosen by eye. But I tend not to stay on those frames after baking, so an automatic rebake would really mess me up

The only use case where that breaks down is if someone were to alter the mesh of a copy, which is entirely forseeable (and a case that I currently support, since I am prone to doing so *a lot*).

Because of this, I'm looking more at culling before the image is saved to disk, as opposed to "before it's baked."


The end goal being to make the process quick and painless, with as few manual steps as possible.