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

Only to argumentative ratbags who take things out of context and read more into stuff than was intended

The standard sphere would fail on a mesh check. That's why it'd be better in export_lsl checking the final sculpt map.

ah... then i would not even have the need to know from which NURBS type i started. So in principle i could just start from a standard NURBS (as i do right now in nurbs2sculptie) and let the sculptie baker determine what mesh type would fit best. Just 2 questions:


1.) for sphere and cylinder the mesh topology does not differ in blender,
only the starting shape. So your algorythm should only need to determine between:

plane
cylinder
torus

In principle the difference between cylinder and sphere becomes significant only when importing into SL. There i must declare the correct mesh type by hand anyways and it should only either let the ends open (cylinder) or close them (sphere)...

2.) The sculptie sphere has got a little hole at the poles. I argumented long time ago, that this would make texture baking less problematic due to distortion effects at the poles (black triangles in the textures). Now wouldn't your algorithm tell you, that such spheres with holes at the poles are cylinders ? (is it that, what you mean by your remark above ? But what can you do then during sculptie baking and why would it be important to find out about the poles ? It would not matter for the SL importer since cylinders and spheres are the same (as noted above)... But maybe the sculptiue baker could profit from such an information ?

probably i am again overlooking something ?

Hi. one more remark concerning the use of alpha in sculptmaps/textures

currently you have to enable Alpha explicitly on the scene window (F10) by selecting RGBA.
I do not know if that is possible at all, but the idea just came up in my mind:

When select "protect map" or "use silhouette" or "use image", i create an alpha-enabled sculptmap/texture. It makes no sense to automatically enable RGBA mode then, right ? that would potentially disturb other workflows, which might rely on the specific settings of RGBA in blender.

But would it be possible (and make sense) to add a button "bake to disk" in the bake environment ? this bake to disk would bake the sculptmap with alpha, and directly store it on disk (if stored the first time a file selector window would pop up, subsequent calls rebake to the same image on disk, maybe warning that they are about to overwrite existing data)?

just a guess... fr0m what we discussed yesterday, a [bake to disk] button (or a checkmark) would again bring functionality fr0m the blender gui to the script-popup, right ?

Yeah, that's what I was referring to. It shouldn't have a hole in the sculptie map though.

There's only two places in my scripts where sculpt type is important. When adding a new sculpt mesh and when exporting to LSL. If the LSL export can determine the sculpt type from the map, then the baker no longer needs to prompt for missing sculpt types. Maintaining the type all the way through the process is no longer needed. It'll slow export down slightly, but the payoff elsewhere is worth the trade I think.

now i start commenting myself lol. Is it possible to "find closed loops" in x or y ? then:

if no loops: then type=plane
elif loops in x AND y: then type=torus
else -> type=cylinder

It'd be a misplaced option. If I was adding a bake to disk option, it'd end up as something like "File - Export - Second Life LSL"

The pseudo code I gave earlier is essentially correct. Just need to plug in image sizes and seperate the x and y loops to support oblongs. I'm working on it now.. (hit quote on this post to see the tab spacing)

def mapType( image ):
poles = True
xseam = True
yseam = True

# need to do the loop on image tests here yet

if xseam:
if poles:
return "SPHERE"
if yseam:
return "TORUS"
return "CYLINDER"
return "PLANE"

And what about adding this to the bake popup:

[Add Poles] or [Close caps] or [Spherical]

Of course the button only appears if the sculptie has a "cylinder topology". It is a toggle button, which is preset by whatever has been determined beforehand by the script.
But at the end it is the user who decides to either close the caps or let them open.

Again: using the default settings is the best choice. but just in case...

would that be feasible ?

What's the use case? I see this as a modeling issue. Automated pole generation would need to be reimported and checked, so why not just close the poles on the model before baking?

Would it give me advantages to use the vertices at the poles in my model and tell SL to close the caps (by defining the object as spherical) ? Does SL take the top/bottom rows and collapses them in that case, or does it add an extra vertex at the poles ? in the first case the Button would not make sense, in the secnd case it would be a nice feature. i fear, the first case is what we are aiming with, right ?

probably i was biased by how the scripts work today and the fact that you can not change the sculptie type, once it was created (ok, i can do that in the logic tab ...)

Yes.

Well, the new code can potentially remove that setting completely. It's not as simple as I thought though. I'll need to handle sizing spheres differently as they use the sculptie type with the special value of 0, also it looks like there is a bug in the triangle fill routine giving minor inaccuracies on unused parts of the top pole edge. SL doesn't use the entire row so it wasn't an issue, but this method of identifying the map type does, so it needs this fixing.

Maybe unrelated, but i found a weird problem with texturing sculpties. (It has even been filed as a bug recently) and it has to do with the uv map and mesh coordinates. the problem is, that when you create a sculptie sphere, then do some sculpting, then later render -> full bake the textures to an image of lets say 512*512 pixels, then i see dark pixels along the triangle edges. this is what the blender developers say about it:

I did not fully understand, how this may be related to the way how you create the uv map, but there might be a dependence, because when i unwrap the mesh to anything, then bake, the pixels are gone. But i can see the same effect, when i start with a plane, unwarp it, then subdivide it, bend it to a sphere... So i think, it is not a bug in the sculptie uv-map, but maybe something can be done on script level as a workaround ?

Anyways after reading the explanation from blender, i found the following workaround:

- i go to the uv editor
- i select all uv vertices
- i scale by a factor of 0.9999

after baking, the pixels disappear.

It looks like a bug which was introduced some time ago, maybe in blender 2.48 or even earlier ? Anyways, does anybody else see this effect, or has anybody an idea how to get rid of it in another way as i describe above ?

cheers,
Gaia

Hi all;

Thank you for all your usefull input and special thanks to domino for clearifying a lot of issues. I did not follow all advices though, but i significantly changed the layout of the sculptie creation dialog box:



All buttons have clear tool tips as minimal documentation. At the end this interface look much cleaner (for me), so i do no more need the simple mode vs. expert mode toggle. I think this interface serves both (unexperienced and experts) in a perfect way.

BTW, now you can switch the build mode in a true radio-button manner. The same is true for the mesh type now.

I only have to understand now how the event system functions in blender, then i can release what i have

Looking better. Are you sure you don't want to replace the UV dimensions with a LOD display for the selected values though? It'd save having to refer to a LOD table to know exactly what you are going to get.

Eg X Faces 16, Y Faces 4, subdiv 1 would show:

LOD0: 9 x 4
LOD1: 16 x 4
LOD2: 32 x 8
LOD3: 32 x 8

I think knowing how the final sculpt varies from the model is much more useful than knowing the final map size. I think the relation to the input and final map size is a complexity most users just don't need to know. What they do need to know is what inputs give the desired output and this display would help with that.

e2a: It's worth pointing out that all UI and event code will change with Blender 2.50, it's why I stuck with the limits of a pupmenu rather than coding a full UI just yet.. Going to have to rewrite it then anyway.

That is allready on my todo list.

My plan is to derive the LOD display from the current settings in facecount and subdiv. So when i change these settings, the LOD-values are automatically updated. From what i read in your readme this derivation should be possible to do without ambiguities ?

And yes, i am aware that this GUI programming is something i might have to dump when blender-2.5 gets out at the end. And therefore i try to do it in a way, that i can reuse it later, but that needs time and skills which i still have to build up.

Having map size as an input makes it a little more complicated. What do you display if user enters a map size too small for the face count? If user increases map size, should face count or LOD be increased? What if a map size ( 64 x 128 for example ) breaks LOD for the current face count?

Hence why I went to the trouble of figuring out the math to automatically generate the map size. It avoids a lot of complexity that way.

ok, ok I did not mention map size in my previous post...

I now tend to skip that too in favor of simplicity. the main reason that i introduced it, was to allow presetting arbitrary face count/subdiv values and still have a "predefined" mapsize.That makes some sense when only 32*32 sculpties would be possible at the end.

But now while oblongs slowly get into my perception(?), i realise that the situation gets different. At the end i have understood, that the map size defacto defines what an oblongs is, right ?

So this seems true :

If i had a 4-x, 256-y 0-subdiv setting,
the map would be calculated to 8*512 image
and that maps to an oblong of 4-x 256-y in SL

If i would change the mapsize to 64*64,
then bake again to the new map,
i would end up with a standard sculptie of 32*32
regardless of the face counts in my model.

And if that is the case, then i get the impression, that allowing to preset the image size makes more trouble than it gives benefit.

So if that is correct, i can happily skip the UV dimension settings
And then the last button "clean LOD's" has finally found a good place below the LOD map...

Bingo

Now how do you plan on showing that the "Catmull Clark" or "Simple" option is only relevant for "Subsurf" build type?

Can i grey out inactive buttons ? not so easy though

But wait a sec...
erm, to my understanding this is only relevant to multires build type. you teached me yesterday, that for subsurf it is irrelevant...

Go back earlier to /8/39/319195/1.html#post2419094

Try adding a multires 2 sphere. Then add a sphere with 0 subdivisions and manually add 2 simple multires. Then add a sphere with 0 subdivisions and manually add 2 catmull clark multires. You should now have 3 completely different sculpties.

e2a: if you wanted to use either of the later ones, you'd add the sphere with 2 subsurf, delete the subsurf modifier and add the multires - this way the map size is correct.

yes, that proves that the subdivision type choice gets relevant when you use multires. With subsurf the choice can be done later without any difference, because subsurf is a modifer. And hence for me it looks like preselecting the subdivision type makes only a difference, when you create a sculptie in Mutlires-mode... (not in subsurf mode as you stated earlier)

What is it this time, that i do not see ???

Um, no it doesn't.



That the script multires sphere is different to either a catmull clark or a simple subdiv one. The script is responsible for the vertex positions, not the multires system.

Ok, i think i finally found whats up... There is a big difference between the release scripts and the RC scripts!

What you say is most probably true for the release scripts. But in the RC scripts you have changed something, which makes the object creation dependent from the subdivision type. There is also this "lemon shape effect" which makes standard spheres look like lemons...

Look at these threads:
/8/c4/312100/1.html
/8/45/312216/1.html

In the secnd thread, post #12 you find a related remark. And in the RC-4 scripts i added a mathematical correction to the problem...

I have meanwhile also verified with my script version which is based on the RC-scripts, that switching the initial subdivision type DOES make a big difference for the object but ONLY if i use multires!

So if you will ever change your scripts back to how the release scripts work, my subdivision choice button will probably get fully obsolete. But if you keep it as with the RC scripts, it affects object creation but only for multires mode.

Whatever comes out of our on going discussion about multires and subdivision type... It turned out to be easy as making a cake to hide the subdivision-type selectors when they are irrelevant. So at the moment you got me so far that i hide them unless the build type is multires

And now i am confident that i also can solve the LOD-display.