The JASS-addon for blender ("domino reloaded")

Hi, all;

I have been busy working on Domino's scripts for quite a while.
I now have got something, which i think is worth a try:

JASS is mostly an add on to the Domino scripts. I did some modifications to the
GUI, rearranged buttons, added tooltips, and added some functionality. The JASS_Library
is also embedded.

JASS is almost ready to go now, but i am unsure, if i should publish it at all. From domino's remark on his thread i learned, that there is no problem with releasing it.

The main point which worries me, is that i needed to do some modifications
in the core package in order to get my add ons working. So i can not offer the JASS scripts "on top of Dominos scripts" which i would have preferred, but i must release the full package "based on domino's scripts", which of course puts the whole burden of maintenance on my own shoulders

Anyways, here are 2 screenshots showing the "simple"- and the "expert"- dialogboxes"

The creation dialog:


- more user friendly interface
- added basic NURBS support
- added subdivision type selection ("catmull-clark" and "simple"
- added LOD display (interactive)
- all Dialog entries are now preserved.

The bake dialog:


- added support for alpha mask from arbitrary image
- all Dialog entries are now preserved.

If anybody is interested in helping me doing some beta testing, please ask me here, or by IM or by EMail ( [email]gaia.clary@machinimatrix.org[/email] ) I will send you a copy of Jass (1.0-alpha).

Gaia, I guess Basic Shape 1 is sphere but is there any reason to use shape 1, 2, 3, 4 and not sphere, cylinder, plane, torus etc?

unfortunately yes. The reason is that the GUI-tools used here are very limitted in their capabilities. Indeed i have found a good replacement for it, but it takes some more time for me to set it up. So i did not include it into the JASS-1.0 release, but i plan to publish that in the next release. Meanwhile this is just an enriched and rearranged GUI derived from the original Domino scripts.

ahh ok. I'm tempted to offer to beta test but there are a limited number of things I do in blender. I have my workflow and haven't explored a great deal outside that. Been a bit busy to do more sculpting but I do have some sculptie stuff on my to-do list.

Hi, Prajna; Are you still interested in checking out my blender add on for dominos' sculptie scripts? Then i will give out the download link to you (and of course also to whoever else is interested to help me a bit ).

The main reason why i do not publish the download link yet is, that i want to get some feedback from experts, if Jass improves workflow and if it is worth the effort to continue with its development and what i should add/change before releasing it.

One very crucial point is still, whether Domino is willing to modify some of his interfaces, so that i can cleanly separate my stuff from his. At the end i have mostly added user interface enhancements and added some new features like the JASS-library and Nurbs support, which are not directly related to the Domino-scripts, but use them under the covers...

So any help would be appreciated... If you like, i even can publish the alpha-version of my Jass-1.0 feature video, where i show how jass is intended to be used (which of course implies, how the domino scripts are intended to be used)

any feedback would be soo welcome ...
cheers, Gaia

Certainly I am interested and willing to help test them Gaia. Sadly I have a major event approaching this weekend, for which there is much work still to do, and I have been getting stuck into adding some content to the LSL 101 wiki entry, so it will be some time before I get a chance to focus back on blender.

Just from the interface:

Why "Use Nurbs" button? Surely the "Use Subsurf" should become a list of "Subsurf, Multires, Nurbs"?

Why simple and expert modes? Where else in Blender is anything done like that?

UV size could be useful, I'm planning on that for the Blender 2.50 rewrite when hopefully it'll be a lot easier to do a fully interactive UI.

That is a very good hint


Well, i think blender could win useability when they would offer/use such a mechanism I decided to go this way, because at the beginning i had big trouble to understand each single button in the original interface. Although you can tell "just keep everything as it is and klick on OK to use the defaults", i think, the average user will be glad to see a trivial interface (the simple one) with the most important selection choices, while the expert can and will use the expert window all the time.

BTW the settings are truly persistent now (i found a hidden bug in the rc-candidate, which prevented the settings to be refetched fr0m disk after blender restart ), so if you select expert mode once, blender keeps it for you until you decide to switch back to simple mode

An alternative would be to use some sort of configuration settings, which are maintained elsewhere and define if simple mode or expert mode should be used. But i did not feel comfortable with that solution, so i worked out the one you see in the screenshots.

The main reason why i introduced this was, that i can now play with subdivide, x-face, y-face independently fr0m the map size. For instance i can now:

1.) create a sculptie with these settings:

mesh type:
sculptie type 4 (cylinder)

geometry:
x-faces 4
y-faces 4
multires
subdivide 1
simple subdiv

uv-map:
dim-x 64
dim-y 64

2.) go to edit mode, and collapse the top and bottom row. then scale up everything except the top and bottom points by a factor of 1.333 in z.

3.) add 2 levels of subdiv (in simple mode)

4.) bake

and the cylinder is done without extra fuss (and the sculptmap has the expected size for a standard sculptie).

http://www.blendernation.com/2009/04/17/interview-with-ton-roosendaal/

Listen carefully to Ton from 2:09 to 2:53 where he explains why Blender's interface is designed for the expert

Dumb down Blender or smarten up the users? I prefer smart users myself..



That fix needs to be incorporated into my scripts then

I won't breakdown your example, but basically you are moving functionality from the Blender UI up to the scripts level. Even when I redo the UI for 2.50, I'm not convinced anything other than a width / height display for the final sculpt map is needed.

It's fine to disagree with me and take your fork of the scripts in any direction you want. I just thought it's worth explaining why I do things the way I do. Just a pity my wrist has delayed the documentation on the RC scripts that would have made things more obvious.

Then why add the sculpt map size functionality to your scripts? It's already capable of baking to any image size if you give the sculpt a new image of that size, and adding that functionality is just making it a tiny bit easier. (5 clicks easier)

I don't mean to say don't do it, or anything like that, just... somehow that statement along with your intention for sculpt map size control in the scripts seems contradictory. I'm honestly not even sure how, but I'm running on no sleep, so it may really have no merit at all.

Oblongs and undersized sculptie support made it impossible to have a default size that is always right. Generating the size from the faces and LOD levels was the next least intrusive option

Yeah!!! I like ton's remark about the piano, which will not make concerts for you, but you need to know how to make concerts with it I listened to the whole interview and i got somehow excited about beeing a small part of the comunity

Creating simple api's does not contradict at all to that! I do not think, that dumbs down the tool (blender), but imho it smarts up the scripts! Why? Because i think, it can help to get more people into "playing the less complex scores" before advancing to ..., Escher, Bach and Domino (/me always kidding ...



It is stupid simple: Blender does not like registry names with a "-" in them. Somewhere in the process it interprets the symbol as subtraction and faces a syntax error. I just replaced the "-" by underscores and that did the trick. And i added persistency in the bake script. i think, that was not implemented in the rc scripts...


There is a good reason why i introduced the catmull-clark/simple button: When you start your work with multires or subsurf, the subdivision algorithm takes care that your sculptie gets subdivided smoothly (hence catmull-clark). But what if you do not want that ? the cube is the prototype case for the problem... If you do not provide the algorithm-choice during creation, you must add subsurf/multires after creating the sculptie, or you must go down to lower levels of subdivision, then remove all higher levels and add them again. Or you must invent another trick (like moving the uv-coordinates).

I found that disturbing and contraproductive to some extent. Now with the new GUI i can tell, "you must choose the values here, because this and that". Everything is at place and makes perfect sense (to me at least). Befoire it was somewhat complex and sometimes it took me a while to even understand the possible other (though very clever) ways.

BTW, don't your scripts do also move functionality from the blender gui to the popup ? You introduce subsurf and multires through the scripts. You just do not give the choice between catmull-clark and simple, so in principle i could argument, that you have gone only half of the way by introducing subsurf but "forgetting" the choice of algorithm. (no this is not meant as an insult! just in case of missinterpretation...)

Introducing the Nurbs button in the creation popup is a contribute to an incapability of blender itself, which later can not tell what kind of nurbs i had created before(donut/plane/sphere/tube). Hence i create them from the popup where i can add the necessary properties in order to allow later baking from nurbs 2 sculptie without intermediate steps.

Absolute agreement about the right to disagree
What would life be, if everybody would think in the same way ?
In that sense i am sure, disagreement leads to improvement.

cheers,
Gaia

My current workflow:

Add sculpt mesh with subsurf to get highest LOD required.
If needed change subsurf type to Simple on modifier panel.
Model and set curve values.
If more modeling detail is needed, decrease subsurf by a level (or remove if already at level 1) and add a multires layer of the same type as the subsurf was.
Finish modeling.
Bake sculptie.

Any UV co-ordinate tricks are just for working with oddball mesh sizes. The only other trick is removing the subsurf (as the bake script does the equivalent of a simple subsurf anyway) when roughing out a sculptie for a quick bake and reimport.



The subsurf / multires choice affects the mesh generation and has to be there. The subsurf type is an artistic choice that can be changed at any point so it makes sense to teach where it can always be changed rather than making it appear to be a creation time option. For multires, the scripts set the vertex positions not the multires, so it's not applicable there, either way you get the same result. Changing it would just affect any future levels you added manually.

It drives me crazy that i seem to not understand a very basic principle here if i do not use subsurf or multires during object creation, but add one of them immediately after the object is created, i end up with the same results (as long as i keep with Catmull-clark). (edit: ok, i see now, the sculpt-map is different, correct).

But concerning the other stuff with the cube: Please can you tell me at which point in my argumentation i make the big mistake ? Lets take again the cube example. it is the one which fits best:

1.) a cube needs 4 faces along x for obvious reasons.
2.) it needs at least 3 faces along y where the top and bottom faces will be used for the top/bottom sides of the cube.
3.) And it looks obvious to me that a cylinder is the correct base mesh object.

But now trouble starts for me:

4.) I want 1024 faces aka a 64*64 sculptmap. so i use 4 faces in y , 4 in x, and select 3 additional levels of subdivide. that sums up to 1024.

Ok, the sculptie is created. I get a nice round shaped cylinder. But not a cube. i proceed by:

5.) go to the lowest LOD level,
6.) remove all higher levels of subdivision
7.) select Simple subdivision
8.) add back all higher levels of subdivision.

step 5-8 look artificial to me , directly induced by the method i used to create the cube.
And for me it is obvious that the main cause of this is the fact, that i could not select simple subdiv at the very beginning of the process. So the process has forced me to go along an unwanted path.

If i had the option to use simple subdiv right away, then steps 5-8 would simply not be needed... And what makes catmull-clark superior to simple subdiv ?

Somehow for me it is like baking an apple pie, but use pears as place holders and replaces them by cooked apples after the cake is finished ...

ok, i still assume, that i have got a big fat knot in my brain which i seem to be unable to get rid off

Just do step 7. I think the difference between multires and subsurf is confusing you. Multires uses the setting when you add a level. Subsurf is a modifier so you can change it at any time.

Arghhh... /me bangs her head on her desk... ok, ok. I got it! For some reason i always thought switching from catmull clark to simple in subsurf mode would give the same result as in multires. Damn...

thanks for the clearification, domino

You could always check the mesh in your nurbs to sculptie script.

Something like...

pole = TRUE
xseam = TRUE
yseam = TRUE
for x = 1 to 31:
if vert[ 31 * 32 + x ] != vert[ 31 * 32 + x - 1 ] then pole = FALSE
if vert[ x ] != vert[ x - 1 ] then pole = FALSE
if vert[ x ] != vert[ 31 x 32 + x ] then yseam = FALSE
if vert[ ( x - 1 ) * 32 ] != vert[ x * 32 - 1 ] then xseam = FALSE

will give you the flags to check to determine the type.

pole + xseam = sphere
xseam + !yseam = cylinder
xseam + yseam = torus

e2a: Actually I'll do this in the export_lsl.py script from the sculpt map. It would make a fair bit of code redundant and simplify things.

Meaning if you don't know blender's interface then you're stupid?

I hope you realise what a silly statement that is.

Iv'e been using your script set Gaia.
One thing is: I made an oblong map.
The map produced is only 8 pixels wide. I create a new image 32 wide and thats ok.

Can a minimum size, x or y, whichever is smallest, be made as a default size? Like no smaller that 32 or 64

Probably introduces other issues. I dunno.

What is wrong with an 8 pixel wide map ?

It's very small.

if you have created an oblong with 4 vertices in x and 256 vertices in y then i believe that the size of the ideal sculptmap is 8*512 pixels... And in general: a mesh with x * y faces will have a map with (2*x) * (2*y) pixels. Is that wrong ?

in general smarten up users is not silly I meanwhile have understood, why there are doubts about adding the subdivision type to the interface. It makes pretty much sense to build the GUI such that the user has got the minimal set of options to get the maximal set of possibilities. Dominos (optimal) building strategy simply does not need to have the subdivisdion type defined ahead.

After sleeping over it i tend to keep the button in the jass-interface because it still is not completely useless to have it there. if i decided to not use the optimal strategy (subsurf ++) but multires for unknown reasons then i might want to have that button at hand... But i need a coffee to think over that in more detail

Ok. I don't know what I'm talking about.
The end.

Thanks for this idea too. I will check that algorithm later, although i got some cases where i am not sure if it would break. i need to get back to this tonight