Blender Sculptie Importer - Attached

it looks to me as if you made a mistake here. check before anything else:

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

watch the last 2 minutes! They tell you the best method to go.

here is the original transcription of the video:
One word about blender and alternatives: Every day i get a tiny bit more of knowledge about that program. And every day i think, that it was worth the whole effort i put into it. It is complex, yes. It has some ugly parts, yes. The graphical user interface is somewhat questionable, yes. But blender is also something you can get used to work with. And once you got the grip,you realise that the GUI gets more or less unimportant. Unfortunately i do not have experience to compare blender with other programs though. But i am happy with what i have and soon i will start checking out the animation capabilities (which i never thought i will ever do when i started with sculpties last year).

Actually, with some experience of other modelers under my belt, I'd have to say that Blender has probably the fastest ui for selecting moving rotating and edgeloop tools around. The soft selection of verts as opposed to box selecting them is a -real- speedup when you have to deal with a lot of vert pushing. If there are other programs that can do this I'd like to hear about them.

Totally agreed Dom Raz and Gaia. I have seriously considered using other applications, of which I would say 3dsmax becomes the most interesting due to its industry standard... But when ever I try them I feel like there is no reason not to stick with Blender. Not to mention when I start hitting a and b etc. instinctively, making whatever editor do all kinds of crazy things it leaves me cursing the menus and mouse clicks.

There are things that other programs may claim to do that Blender does not, but if you have been following the development path of Blender especially recently, its just a matter of time before that feature will be incorporated into the trunk. I'm thinking primarily of the texture painting improvements as well as the new sculpt brushes.. IMO it now rivals or is even better than Z brush in these areas where Z brush really had a lock on the market a couple years ago.

-w

Just wanted to add, it kind of bugs me how all the other big 3d apps are owned by autodesk now anyway which is bordering on a monopoly from what I can see. Why not support the open source community?

There are other programs.
They are most commonly: XSI/Max/Maya/Lightwave...and Blender
Very few of the other dumbed down 3D applications offer anything like the same level of control or interface awesome.

As with everything, challenge is proportional to reward.

When I used Max professionally I couldn't understand blender.
After taking a 2 year break for anything 3D i picked up blender and instantly it clicked.
I still regularly have that facepalm moment where i can't understand why i never 'got it' before.
I haven't played with XSI/Max/Maya/Lightwave for years, but it's hard to go past Blender. It truly is one, if not THE most awesome feebie application in the universe.

But for those of us who want to be able to do professional level 3D without having a commensurate level of knowledge of the app they are using, and the methods involved... well basically you can't.

The fact that Blender has its roots in unix makes it a little more complex to install/understand. But that additional difficulty is totally minuscule. It does mean however that generally we need to make a significant effort to get a basic understanding before knowledgeable people will even attempt to help.
Knowing the basic terms, and what *can* be done, and never once whining about how 'application X is better' or 'isn't there just a button i can push so i dont have to learn all that?' will assist in being able to communicate with persons already skilled in the use of such things.. a lot.

However blender does do everything from first principles, which not only makes it inherently simple, but if you can learn Blender, you will understand the basis of any 3D application.
And to be honest it's not really that complicated once you do start to get a grip on it.

Ok i folllowed what it said.. and Seen the scripts from the folder i input, but now when i go to import scripts i get :

Python script error, see console

I am new to blender but i am very good with computers, so i know i set the path right. What else could i have done wrong?

What are you trying to import then ? it MUST be sculptmaps... In order to get a fast entrance to sculpties with the domino scripts, you might want to watch a 5 minutes video introduction here (and it works for all versions of blender starting from blender-2.46!):

http://blog.machinimatrix.org/2008/05/12/blender-sculptie-creation/#more-11

and this video here will help you getting around the first steps with blenders editor:

http://blog.machinimatrix.org/2008/08/24/the-blender-primer/

have fun,
Gaia

Pasting the error message from the console window would be useful too. :]

Greetings!

I've got a somehow frustrating problem...
I am using Blender 2.48 and Python 2.5.4 (I know, the console says something else..) and Dominos newest script version.
Before I've been able to test my skills in creating sculpties via Blender, I got
the famoust "Python script error". This is the third day I am trying to solve the problems I am having with the Triangle formed by Blender, Python and Dominos scripts.

This is what my Blender console spits out:



I hope there is someone out there who can help me solving the problem, or at least someone who gives me the needed push in the correct direction.

Blender does check for the existence of a specific python-version (2.5.2) in the case of blender-2.48. It seems it is capable to also check for compatible python versions (i did not know that until now You got a newer python and blender seems to be happy with that. But that does not matter anyways. You do NOT NEED to install python, because blender comes with a stripped down version of python and that is sufficient for running the domino scripts.

Concerning the output of the console:

blender searches for python 2.5.2 and found something compatible...

A known error in the scripts. The effect is that the GUI-settings for the sculptie popup menus are not getting persistent (i truly minor problem

This is a mixing up of release-scripts and rc-scripts.

the best todo here is:

1.) remove all scripts related to domino design
2.) follow the instructions from here: http://blog.machinimatrix.org/2008/07/12/the-blender-installation-guide/ The transcription of the relevant part of the video tutorial is included below:



Have fun

Oh gosh... thanks alot ^^
After so many researches I finaly found someone who know what he/she is talking about
Thanks you so much!

(One thought at the end: Maybe it was this hard for me to find you allready existing movie instruction because english isnt my native language. Others might have this problems too. Translations of your webside and videos might be a good idea. I woulnd't mind to write a translation into german as some kinda... repayment for your fast and professional help.)

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

The git repository is up at it's new location. Word of warning - there's lots of untested development work in there at the moment. And yes that means new stuff is coming, including two ways of creating linksets

Hey, that is "the message of the day"

So the maintenance branch on the machinimatrix site gets obsolete. Now i could happily drop my fork in principle...

If you would consider to split up your code into 2 parts:

The "primstar-gui" which handles the user interface only, and
the "primstar-core" which implements the algorithms ( without any user interaction parts)

Then the primstar-core could be embedded into other infrastructures and the upgrade to newer primstar-versions would become easy(easier) ...

What do you think about that idea ?

Something like that will eventually happen. It's on my todo list for the Blender 2.50 rewrite. Most of the scripts expose their key functions already in preparation for this.

Some of your fork will make it into my scripts. I need to get my current development path tested and debugged before I can consider what to merge.

Love you Domino and Gaia.

Thanks Tiziana

For anyone who's brave enough to be testing the git repository version, a quick heads up: a "sculptie" UV layer is now required. This is a change I've been planning on making for a long time (which is why I added it to imports and new sculpties way back in the mists of coding history). This change affects all the main scripts and has simplified things in places. Import now just needs a filename to do it's thing for example.

The other main change is proper linkset support. Razz Welles has kindly been helping me to debug the LSL. I can't login to SL at the moment to test things myself, so the feedback is much appreciated. You can use the parenting in Blender to create linksets and File - Export - Second Life LSL to save them.

The other way of doing linksets is to assign a mesh to multiple UV images on the sculptie map. The easiest way to do this is to add multiple sculpt meshes, join them in object mode, then merge the edges as appropriate to create the bigger mesh. Make sure you join at the same LOD on both meshes, and subsurf etc will work across them. The disadvantage to this method is that you only get a 256 x 256 x 256 sculptie grid no matter how many sculpties make up the mesh. The advantage is perfect seam alignment across multiple sculpties and easier workflow than aligning separate sculpties in a parented linkset.

Both techniques will work together, so you can have multi-image sculpties as part of a parented linkset.

There's also a change to the Mesh - Scripts - Update from sculptie function. This is now only applied to selected faces, so you can use it to copy a section from one sculptie to another. It's also useful in remapping sculpties as you can create a new sculptie with add mesh, then use this to align the mesh with an exisiting sculpt map.

With so many changes under the hood, there's probably a new bug or two. So if anything unusual happens let me know as it might not be intended behaviour

Now where's those kind people who turn my techo babble into user speak?

http://dominodesigns.info/second_life/blender_scripts_git.html now has a test blend file for the repo version of Primstar. It's an example of multi-image joined mesh sculpties.



OK, I set smooth for effect, but that is a single mesh that bakes out to two oblong cylinder sculptie maps. (note: Fill Holes needs enabling for the bake)

Here's the imported sculpt maps at LOD1. I've not scaled to match the original.

(Message has been split to two parts, because the forum software 403s when posts are too long)


Present and accounted for. I've been making lots of oblong sculpties of late, so I have some comments.


As a summary, I'm assuming you're talking about:

* Making sculpties load based on the dimensions of the input image
* Properly handle link sets when imported to SL, vis Blender sets
* Properly merge multiple sculpts into a single prim, within the constraints of a single sculpt

This is a somewhat topical summary, but should be simple enough for most people to understand.


As for my comments:


This is a good thing. I actually modified my own copy to perform something like this, so having it in the official build is a plus.



I think using Blender's parent system makes sense here. No complaints.



This seems like a strange way to do things, but I can see the desire for aligning multiple maps together.

On the note of getting the seams woven together, I've been looking at creating an export tool that generates sculpty* "patches" from a mesh. There are LOD and seam issues to work out, but I'm fairly confident in this method of export.

(To this end, I'm looking at the ability to "merge" edges in the client code itself. Been wanting to do that since 2005.)


This is interesting, though I propose an alternate method: the ability to generate "template" sculpts for combining faces in a paint program or a full sculpt. This has been my workflow.

The trick would be to define a useful sentinel value for the mask. Using an image's alpha channel might work for that.

Works so far for me.



Great minds think alike. I'd been doing sculpty merging with GIMP, and accounting for the hit in detail on the raw image. Being able to merge maps like this /should/ save time, though at this point, I'm accustomed to working with the raw image.


On this note, I'd like to share some of my own feature ideas that I've been looking to write (straight from my todo list):

* Sculpty watermarking (ie, a copyright notice), using the alpha channel.

* A visual representation of "vertex drift" on a live sculpty.

(By this, I mean being able to visually see where the vertices are when constrained to the old 256x256x256 color grid, in real time. For now, save and load works.)

* An option to "smooth dents" by slightly enlarging pieces of the map.

(You know what I mean: those annoying, low-LOD pieces that come out dented because the color rounds off.)



All in all, thank you for continuing to maintain this library. I've had to call off some of my own projects due to personal reasons, so it's good to see that progress is still being made on tools for Blender.


-----
* Note I use the somewhat archaic "sculpty" to define names. I just like that rendition better.

Hi, Domino

I have looked at the new code too and i have applied all your changes
to my own scripts and i did not find any new problems, so it works for me too.
I have one small problem with precision though:

I create a simple "standard cylinder" (8*8 faces, 2 Levels, Multires mode). In the left
you see the original (directly after creation), on the right you see the reimported sculptie.



Below in the closeup you see, that some vertices have jumped away from their expected destination. Interestingly i can move them back at place, then bake again and reload the sculptmap. Now everything is correct.



Can you verify that behaviour and do you have an idea, why that vertex shift might happen ?

I think, that i have implemented that feature in my modified scripts (the jass- distribution) by allowing an arbitrary picture to be copied into the alpha channel, so you can watermark or add whatever you like (logo, etc...)

I do second that opinion. Especially because "oblong" is a missleading term when smaller squared maps are involved. But for some reason i tend to use "Sculptie" for a single instance, which probably is not correct in terms of english grammar

I suspect it is a rounding difference, not sure where it is occuring though.

On my todo list is to convert the sculptie generation routines to generate the map first rather than the mesh. This would in effect apply the 256 x 256 x 256 grid to the new sculpties as they go through the "update_sculptie_from_map" function. Rounding problems should just go away with this approach.

Meanwhile i have checked more thoroughly and i found, that the effect is NOT present in the release scripts, but in all other variants. So it looks like it is NOT blender...

That's where i am hunting for right now

Does your remark above imply, that you are going to calculate in the range [0-255] instead of using the range [0.0-1.0] in your algorithm until you have to render the image pixels ?

I'll still calculate using floats, but set the sculpt map image pixels, then set the mesh as though it's an import. I've done the image part and it's a lot cleaner way of doing things, my only concern is the impact on mirroring, as we get the SL off-center centers with this method.

Sorry for asking more and more... Does that imply that baking will modify the mesh of the object (and limit it to the resolution of the sculptie ?)
If that is so, will you then add a button "keep original mesh":

"keep original mesh" selected: keep the original and only bake the sculptie map.
"keep original mesh" unselected: replace the original by the modified (baked) version.

Does that make sense ? Or am i on the wrong track ?

Wrong track. This is add mesh, not baking we are talking about. I've made the change now in the git repo so you can see the difference if you pull the changes.