Blender Sculptie Importer - Attached

I've changed a lot today (8 commits to git) and there's now a new script called sculpty.py

I'm moving all core functionality there. It's not all there yet, but anyone with a fork won't have a smooth change as there's lots of api changes. Sorry about that. The upside is eventually, anyone with their own interface will just need to import sculpty.py to get all the sculptie features of my scripts. So long term it'll be easier for everyone

The other upside is that the api in sculpty.py all has doc strings, so it's a lot easier to understand than the old versions.

I've half adapted the sculpty naming. It's easier to type so I've used it in the code. I think sculptie is easier to read, so I am still using that in user facing stuff like forum posts

Since my last pull about a day ago: 6 files changed, 611 insertions, 453 deletions

>_> Daaaang, you go Domino!

I don't have the folders specified in the blender installation for my Windows Vista Computer, Where should I copy the scirpts too?

Hey Domino,

current dev. scripts.

not sure what went wrong here or what i am missing, but if you parent two (or more) objects in Blender by selecting them and hitting Ctrl+P in object mode, LSL export still gives separate LSL scripts for each object.

Tried both - selecting just the parent object and doing the export (in this case it outputs just the script and map for this particular object) and selecting the whole set and doing the export (in this case it exports scripts and maps for all objects separately).

Where's the catch?

Havent tried the second method, since that looked more like too much mumbo jumbo for me

TYIA

Sounds like the RC scripts.

With the major changes I'm making to all scripts, the dev scripts are in various stages of broken. Or various stages of improvement depending on your point of view

So just to confuse everyone even more, in addition to the release scripts and the rc scripts, there's the snapshot download, which is a git snapshot from when everything was almost working last. And there's the live git repository which is the real edge of development.

It's this last one which has all the recently discussed changes. I've a few known bugs to work out before doing another snapshot release.

http://dominodesigns.info/second_life/blender_scripts_git.html has the rc, snapshot and info getting the git repo versions.

This is basically the cleanup process as we head for a 1.0 release. Next time I do a RC release it will be feature complete and only bug fixes will be applied until it goes to a final 1.0 version.

Will double check , but i am 90% sure that i took the snapshot one with the date of 23-5-09.

Anyway - got another question which concerns previously released RC scripts. Lets assume that i am developing a multiprim object, where all sculpties are done in Blender. Object consist of several normal size prims and several very small ones, which need to have "keep scale" turned on while baking the map. Then I export to LSL all prims and compose them all together in SL.

What confuses me is why sometimes when you bake with "keep scale" on it bakes sculptie map which cannot be downsized enough, to match the other objects.. I have a feeling that it is baked as it would be without "keep scale" on. And then for some reason when i do re-bake it (just not sure what operations i do need to do prior this) - it starts working fine. Should I bake bigger prims before baking smaller ones with "keep scale".. ?

TY

I think, that all the major changes have taken place on 24-5-09... Maybe pull another snapshot ?

Domino, is it a good time to start migrating our jass-fork now to your git-scripts, or are you going to make more drastic changes to your code in the next few days ?

One of the reasons I've done these changes is to make for a clean merge of functionality from forks

If you want to check the sculpty.py api for any extra features that are needed, and submit patches, or at least an example function call with a doc string:

def protect( image, alpha ):
'''Sets image transparency to the alpha image specified'''

is one I know you'll need for example. I'll get to it eventually, but I'm not going to complain if someone else starts helping to fill the gaps

Keep scale just disables the normalisation. Say you had a 0.5, 0.75, 1.0 scale object, without keep scale, in Second Life you'd set it's size to 0.5, 0.75, 1.0 - with keep scale enabled, you'd set the size to 1.0, 1.0, 1.0 but it would look like 0.5, 0.75, 1.0

Remember the scale is calculated across all selected sculpties, so if you want the most detail per sculptie, bake them one at a time.

I'd wait for another snapshot or get the git repository directly if you are brave. Key features, including export to lsl are known to be broken, so until things are mostly working I won't be updating the snapshot.

Yes, thats the way to go - baking one at a time.

However what to do if my object consists of lets say 5 sculpties from which 2 of them should be nano? The normal sized ones i bake one at a time, but how to bake those two nanos so LSL exporter script (i am talking about full model export here, not seperate scripts per each prim) would still place them in right positions and give them right sizes? Also - i would not want to play with scale calculation for objects which size should not be smaller than .01.. so selecting all meshes in object mode and hitting bake would not be an option.

(nano - sculptie which doesnt take full 3d cube space, but occupies just a part of it, so i can achieve much visually smaller sizes than full 0.01 space)

OR REPHRASING EVERYTHING BEING SAID: Ive created my multiprim object in Blender. Exported LSL which created a multiprim object in SL. Everything looks good, but i see that i cannot downsize this multiprim object enough because of two prims which already have reached the minimum size. Meanwhile i would not want to loose detailing level for other 3 prims. Now the question is - how should I bake those two prims whcih should go visually smaller than 0.01 and still LSL exporter would place them in the right positions and sizes?

I'm going to defer answering this until the next RC is done. There's a long standing bug where it's not always calculating the relative locations correctly. It was looking at fixing this that prompted the code cleanup that's in progress. I'm rewriting the entire baker, so tracking down an existing bug would just delay the real fix. In the current scripts, export_lsl gets all the prim locations wrong, so for now, you'll have to manually assemble this.

OK, will be waiting for next RC,
good luck and thanks for your hard work

I just took a big step towards it. I've just committed the new core bake routines. They aren't connected to the interface yet, but they can be called from a python script. The git log has sample code to do this.

I've done away with the triangle fill completely. The baker is now vertex based and uses a combination of "fill holes" and a modified "compressible" function to complete the map image. As the new compressible is vertex safe, it's now rolled up into the "Fill holes" option.

The only disadvantage to this technique is that it won't be as accurate on low polygon, non gridded uv map models. As the workaround for these is to add a subsurf modifier to increase the vertex count, I think the speed increase is well worth it.

Latest git snapshot has the new baker hooked into the UI.

Still a little work to do on the export_lsl side, so don't bother with bug reports there yet (unless accompanied by a patch to fix it of course )

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

Hi Domino;

I have started investigating on the new git release. From how i understand your concept, there will be only one file "sculptie.py" which will be needed when embedding your routines into another program. All other files make up your specific GUI. If that is true, that is fine

Now i started to play a bit with the tool and i do find everything has changed under the covers ok, it took me months to learn some basics about the old scripts. lets hope i can learn the new ones faster. Anyways i am not complaining here, probably things are getting easier

Let me report some minor points, which i stumbled on during my playing. It may be of no importance, but maybe i better report it to you just in case ...:

1.) precision

- I created a 4x, 4y, 3-levels cylinder (what else, looks like it is my favorite .
- I used multires-mode.
- I went to top view and entered edit mode.

First thing i noticed is, that the sculptmap is allready there. So this is due to the new baker ? Then noticed that something happened with precision:

In the following picture i have merged the top view and the uv-editor to save space.
what you can see, is that the expected square shape is somewhat imprecise (look at the white line). These are the edges in top view. It looks like a one pixel shift introduced somewhere.

Then look at the sculptie map. Why does it look so "pixelated" ?



Do we have to worry about that? Or is this one of the minor bugs you said that you are still working on ? Will we get back the good resolution of the release-scripts ? Or are we going to live with it as it is now ? Is it a consequence of the new baking method ?

2.) baking
Another question raises in the baking-gui. What does "finalize" do?

3.) persistency
The baking gui does not remember the last used settings. Is that on purpose ?

I hope, that my questions are of significance to the new code and i hope i could help
a bit.

Yes, that's how it's organised.


Hopefully they are



No. It's due to the new sculptie generator. It generates the image and creates the mesh from that. It makes it simpler to add new math generators - anything that takes two parameters from 0.0 to 1.0 and returns a rgb colour will work. It also means the generated meshes are sculptie grid aligned, so it's more accurate too.

Why does it look so "pixelated" ?[/QUOTE]
That's the new optimised sculptie format.

It's setup for mirroring and the routine is aware of the sculpt map LODs and protects the appropriate parts of the map from the mirror. So the map mostly ends up as 2x2 pixel chunks, but occasionally rows of 1 pixels will occur.


Maybe.. depends on which commit you tested. The new baker should be more accurate, so if this is with the latest version, it needs fixing. The snapshot is a few commits behind currently.


The baker leaves the alpha channel transparent on unbaked pixels. Finalise finds these and fills them in. It also does the mirroring for the final sculpt map and enables the protection options.


Yes, but only because I've not decided how to handle it yet. It may be better to store them on a per object basis, rather than globally.

ah, ok. thanks for the very quick answer
concerning the version i tested: I removed the complete repository
and then i did:

git.cmd clone http://dominodesigns.info/git/primstar.git

I do not know how to "update" the repository and i do not know if there
are something like version numbers available. But i can tell that i have
cloned the respository about 1 hour ago now. So if you did not add
new functionality during that time, i seem to be on the newest primstar
version in git.

It looks like this is a result of the new mesh generator. If you square up the generated mesh before baking, it's fine. I'll look into it.

It makes sense to keep the settings with each object. But it also makes sense to keep the settings for each newly created object. so maybe the best would be to use global settings for new objects and remember these when creating the next object ? But also keep the individual settings for each object and overwrite the global settings with the object specific settings... When importing new sculpties... they would need to be imported with the "new settings" then...

well i don't know. you will take a reasonable choice anyways

thanks.

"git.cmd rebase" from a prompt in the primstar directory should do the trick. It does sound like you are up to date though. If you have the new option in the UV editor Image menu, then you are current

"git.cmd log" will give you the commit history. The long hexadecimal number is the commit id. Date and time of the checkout is enough reference for me when sending bug reports.

I just did this:

1.) created the 4,4,3 cube (multires, open end caps)
2.) go to edit mode.
3.) rotate along z by 45 degree
4.) bake

directly after baking the sculptie was auto-rotated back along the z-axis by 14.5 degrees. That is truly unexpected

Oh... One more thing: The new baker modifies the mesh during bake and the result seems to be the sculptie in its true shape. Some days ago you mentioned that this would not be the case... see

/8/60/203571/29.html#post2439335

Did you change your mind about that ? Or did i missinterpret your answer to entry 717 ?

No it doesn't. The only thing the new scripts update is the object center. I'm not sure what you are seeing, but the mesh shouldn't change and shouldn't rotate either.

After rotating 45 degrees, snap to grid from top view. This will give the perfect square and it bakes fine.

As far as the new mesh generator, I'm not sure whether to keep it or go back to the old method. This is more accurate for sculpties, but maybe the math version is more appropriate at that point in the workflow.

hi,

testing 27-5-09 snapshot with my existing Blender project.
for one object after baking - object's position has been changed.
I re-positioned the object back where it should be, recalculated center,
baked again.. and booms, object has been moved again. This was not
happening with the available RC.

Also.. if i do scale the whole multiobject thing much bigger (in obj mode) and
then bake one prim individually,.. it becomes X times larger than other objects.

If you can reproduce the problem in a .blend file you don't mind sharing with me, you can email it for testing to domino at the download domain.

All the location and export scale code hasn't been tested much yet (it's also been rewritten), so having .blend files with known problems helps speed up fixing them.