Blender Sculptie Importer - Attached

I think I may have figured out my issue.

Is it true that to scale something properly before baking, you need to do it in EDIT mode not OBJECT mode?

I tried that, and then saved with keep-scale selected, then reloaded the sculptie and it seems to work properly.

Does that make sense?

1-6-09 snapshot

trying to bake texture for a single object which bakes fine with RC:

Traceback (most recent call last):
File "<string>", line 1, in <module>
File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\render_scul
ptie.py", line 182, in <module>
main()
File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\render_scul
ptie.py", line 152, in main
if sculpty.bake_object( ob, bb, doClear.val ):
File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\sculpty.py"
, line 499, in bake_object
maps[f.image.name].bake_float(image)
File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\sculpty.py"
, line 235, in bake_float
image.setPixelF(x, y, ( r, g, b, 1.0 ))
RuntimeError: r, g, b, or a is out of range

(all baking settings are left as is (default), nothing has been changed)

Another thing is that sometimes after baking an object scales itself up in blender and becomes much more larger than it should be.

ty

Scaling is on my todo list. I had to have the import / bake cycle round tripping before I could focus on it. In the recent versions I've taken out a lot of the clipping stuff (so errors in scaling show up better) and the error you are getting is one of these, so hopefully it will go away when scaling is fixed. If you don't mind me seeing the .blend, you can send it to domino at the download domain and I'll add it to my testing.

Sadly with my wrist I can't test the code as much as I normally do, so I really appreciate people taking the time to help me out and test for what's currently broken for me to focus my efforts on.

Months ago i found a similar problem in the RC-scripts and reported it in my commented scripts version . For me it looked like a math problem, which sometimes yields values slightly above 1 or below 0. I never understood exactly when this happens, but after i added a value clipping before setting the pixel color, the RC-scripts never chocked again. I am sure, that your .blend file would be interesting for inspection

The old_rc tag in git has that problem fixed.. Don't tell me I never updated the zip file

Problems with old_rc aren't going to be the same in the git version. It's had an extensive refactor and many sections of code have been rewritten. The change from the scaleRange class to the BoundingBox one was to open up new functionality, and considering it's the most complex part of the scripts, it's not surprising there's a few issues with it. It has to cope with everything from single objects to multiple objects with different modifiers, some could be multires, some could be subsurfed, some could be plain meshes. Some could be scaled by -1 to mirror the sculptie (which will affect the LSL output when I get to that). Some could just be acting as a bounding box, and with child objects scaling with their parents still not supported, there's a lot to do to get this working how I want.

Single prims should just work though, hence my interest in Maris' blend

Btw: if you want your nurbs bringing in, it'll need doing in a seperate module (sculptie_nurbs.py for eg). I don't want to add that to the main scripts until they can be handled without the conversion. For that Blender's api needs an extra function to let me read the nurbs surface rather than it's control points. It's the only thing on my want list, that's not already confirmed to be in Blender 2.50

PS: The reason for the scaling problems is that this rewrite could be called the "less is more" one. The old scripts updated the object's scale, where the new ones leave it alone (bugs in set_center aside ). There's a lot of interaction between different areas of the scripts, so updating one area means related areas need fixing to. The broke one checkout, working the next is a symptom of this which should stabilize soon. I'm bringing in code from export_lsl.py now which is the last thing likely to trigger any significant changes.

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

New RC scripts up. These don't have all the changes mentioned in this thread for the snaphot version, but do have the update I'd missed uploading previously to fix issues on edges of sculpties. They also have the fix for the importer accuracy backported from the latest scripts.

Domino, I've sent you the file which spits out the error message i've previously reported in post #770.

Hope that helps,
TY

Cheers. I get the same problem so should be able to track down what's happening.

Hello I use WINDOWS and i cant find that folder too

See my remark above at

/8/60/203571/31.html#post2449228

I guess, that is what hearts you...

And this will probably help you

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

THank you so much. This helped me find the scripts. Its so funny how something so simple can seem so hard until you finally get it. I have tried all weekend to find these scripts, and the little video told me how. IT also told me how to save my settings, which I had struggled with. I have two Blender books, and this little tidbits do not show up in the Index.

Now, I can find the scripts, and they show up in the Import directory, but I get an error message when I load one, that Blender can not find the file. Is there a tga file I should load?

The other problem I have that when I open Blender, it says it can not find Python, but I have loaded Python twice, what is the little secret for this one?

Thx,
BT

What do you mean by "When i import one" ? And which file is it that blender can not find ?
That sounds like you try to import something into blender which you assume it is a sculptie but in fact it is not... Anyways, maybe you should also look at the other machinimatrix videos ? They are still valid and show some easy workflows how to create sculpties.

How do you "Load python" ? And how can you do that twice? Maybe you meant that you installed 2 versions of python ? Be sure then, that you have got the python version which fits to your blender version. But anyways you do not need python at all, because blender allready got a minimal python which is sufficient to run the Domino scripts...

Hi, Domino;

I am ready to port my GUI to your scripts now. Shall i do that with the RC-scripts, or with the GIT-scripts ?

And how would you like to get the results ? I am very unknowing about git and although you explained it to me recently, i still only can pull(?) the latest version by completely removing my git repository and then clone another one. And i have not a single idea how i can send you my version. The only way i can guess is to zip the whole repository and send it to you ...

Hi Gaia,

The Git version is the active development one, so that's where any new patches should end up. Having said that, if you remember which version you forked against, you could create a branch at that point in the history, add your changes to the branch and commit them, then try a rebase from master. This should give you a branch with your changes sat on top of master. You could then either use git diff to dump a patch file, or zip the repository and email it to me.

http://git.or.cz/gitwiki/GitCheatSheet might help..

and there's a very good explanation on using git for vlc here:

http://wiki.videolan.org/Git#Getting_VLC_or_x264_source_code_via_Git

When I get around to doing a guide for the scripts, I'll be basing it on that.

Hi, Domino;

I cloned your git-repository and applied my changes to the files. Then
i checked that into the machinimatrix repository for my own reference and
i created a zip containing the git-files. The port is here:

http://www.machinimatrix.org/svn/sl/distrib/git-745aacd8de2babbb4cf9ac3824ea8a1845d6b232.zip

I did not integrate the Jass-add ons though. i.e. no NURBS support and no
Image-alpha mask. I think this is how you like it anyways ?

One thing remains open for me: I was not sure if you wanted the catmull-clark/simple toggle-buttons for multires AND subsurf, or only for Multires. From our recent discussion i had the impression, that you wanted them only for multires, because for Subsurf the setting is irrelevant... But since the setting influences the creation of the object, i decided to keep the buttons visible all the time thus making the GUI more consistent (in my opinion).

I hope, that all in all i did integrate the GUI in a convenient way for you and i hope to find it in your RC distribution soon Then i will replace the rc-scripts from the Jass-distribution by the new RC-scripts and apply my Jass-addons there again

Now it starts getting fun again...

cheers,
Gaia

The way that was suggested to see if the scripts are in the right place was to try and import something and see if the Sculptie was on the list. It is there, but when I carry through with the import, it seems to be looking for a tga file that it can not find. I get a small menu that asks what kind of sculpty that I want to import, I choose the default one, and get an error message. It seems to be looking for a tga file while I look at the text under the path.

in principle any image format can be uploaded. You only have to ensure, that it contains 24 or 32 bit pixels. tga will do, png will also do. i am pretty sure other common formats work too. You should take care to only use lossless formats though (tga and png are lossless as far as i know). So whatever you try to upload, if it does not contain the appropriate content, the scripts will choke. i think, the best way to check that everything is ok for you is this way:

1.) Add -> Mesh -> Sculpt Mesh
- In the popup window press OK.
- You get a sphere object.

2.) Render -> Bake Second life sculpties
- In the popup window press OK.
- Your first sculptie has been created.

3.) split your screen and open the UV-editor
4.) go to edit mode and see your sculptie popping up in the uv-editor
5.) in the uv-editor: image -> save

6.) File -> import -> Second Life sculptie
- import the just saved sculptie and see, that everything is ok.

I'm resting my wrist for a few days after the last coding sessions but hopefully will get this integrated soon.

As far as alpha-image mask goes, the set_alpha function in sculpty.py is sat waiting to be plugged into the gui.

With nurbs, the changes to the scripts should make it easier to do (with the map_type function now eliminating the need to maintain the sculpty type throughout). You should be able to use normal Blender nurbs at the add point, and have an option "Convert to sculptie" which does the magic. As this then needs no special handling of nurbs within the scripts, I think this should be a seperate script. When it's possible to read the nurbs surface from Python, and the conversion step is no longer required, then the right place to add support is in the bake_object function.



In the git scripts it's enabled for both, so this approach is right.



Well, if you take on my comments above, the scripts shouldn't need modifying to work with your nurbs stuff and it would be a separate script that could be an add-on or part of the Primstar pack.

If you have ssh access to your webserver, you can setup your own git repository for the scripts that you push to via ssh and is available via http for anyone to pull. The article at http://toolmantim.com/articles/setting_up_a_new_remote_git_repository (and comment 27) has the details.

When creating a zip of the repo, don't forget to include the hidden .git folder, as that has the commit history which makes merging easier.

NURBS support is allready implemented mostly as you propose: a separate script. I originally added NURBS to the sculpty GUI, because the sculpty-type was needed during bake. This is no longer necessary now

Concerning git and the JASS-distribution, there has been a decision here at machinimatrix to continue using subversion. I myself can (currently) not decide, what is better, so i just follow the team here. However i will learn git on my own (as you know i never give up ) so that i can help supporting primstar where possible.

One remark about JASS: JASS was meant as an intermediate development until you are back. Meanwhile it has changed its goal and it now it is an integration platform for several developments with primstar in its heart. The goal is to address those, who like to have a ready made precustomized solution, hence we have added the binary distribution recently.

I see primstar-core to address the more technical oriented blender user, who know how to customize the tool to their own needs anyways. I hope, that many "newbies" eventually end up using primstar and blender plus some of the JASS-tools separately at the end

Does that make sense to you ?

I have just replaced the zip-file from yesterday by a new one containing the .git subfolder. I did not do any git-commands though. I just added my modifications in the files. The repository is now at:

http://www.machinimatrix.org/svn/sl/distrib/primstar-git.zip

I hope, that is better ? I still have to learn the exact workflow with git ...

No need to be embarrassed. It was your work that prompted the rewrite to make things easier for you.



I use git on svn repositories too. It's basically all the same commands but with git svn instead of just git..



You know that basically I like most of the ideas you are putting into JASS? It's just the implementation of them I'd like to see improved. As you've already seen, going for a better implementation improves the Primstar scripts as well. Look at the changes map_type gave. That function came purely from thinking what was needed for good nurbs handling. It's up to you whether you put JASS or Primstar development first, but I'll obviously help more on the latter.



If you see Primstar as aimed at technical users then I'm failing. The current documentation is aimed at Blender users rather than newbies, but that will change once the current git scripts move to RC. Adding a docs folder with html instructions included in the primstar zip is on my todo list.

I will of course put as much effort as i can into primstar. It makes much more sense than forking (which i never wanted to have nor liked to do at the end!) and if you incorporate the new GUI into primstar, it would make me happy and at the end it would make it much easier to create video tutorials for Primstar AND JASS

No, i do NOT see primstar itself to be aimed at technical users! It is well suited for beginners especially with the new GUI . I meant something different in my earlier post:

From all questions and answers about sculpties here in this forum and on the machinimatrix site, we had the strong feeling, that it makes pretty much sense to create an "all in one starter pack" for most easy installation and jumpstart into sculptie making.

So to speak: Your scripts allready take away all the burden during the creation phase, while JASS aims to also remove many burdens from the installation and learning phase...

BTW: Have you seen, that we have added pointers to some of the machinimatrix videos to the Help menu of our JASS-distribution ? That could be another idea for primstar too as it can be added in a snap... ok, python is needed...

Yeah, I'd not realised from the "binary" comment that you were doing a full Blender distribution with the scripts already installed. I'm still thinking of the best way to do an automated install of the scripts. I need to experiment and see if I can set the user scripts dir from a script without altering the rest of the default blend file.

Do you have an email address you want used for the commit message on the GUI changes?

I'll be making some minor changes and cleaning things up.. You've followed my bad lead and have x_faces = something['faces_x']. It's on my to do list to go all through the code and get some consistancy into the use of faces_x, faces_y, u & v, s & t, x & y and all the other variations of x,y co-ordinates I've managed to use I'll probably change them all to use XYZ classes and give them more descriptive names. So things like faces.x , faces.y, uv.x, uv.y and loop.x, loop.y would be used then.

Also I'll be taking out the version you added to sculpty.py - it's git's job to track versions and revision history. I've been taking all that stuff out as part of the cleanup. The snapshot will eventually be automated to update from git once per day. All other releases will be tagged in git.

sure... [email]gaia.clary@machinimatrix.org[/email] will do
And i have no complains about any changes to whatever i provide. I think, i still have to learn a lot about python and blender and the API ...

We have found out how we could package scripts into a subdirectory. The current JASS-1.3 distribution has that allready implemented. So you can drop the jass folder in its whole to the user scripts directory or to the system scripts directory. And later when you want to remove the stuff again, just delete the folder... No more mixing up files with the official scripts or with other add on scripts... Maybe that can be a small step towards your goal ? At least it would help a lot to keep things cleanly separated...