About Sculpty Collision

Hi all,
I wrote a little tool.
It does a trick that allows you to fix the space around the Sculpties in the collisions.
It is the first code, so it is possible that it has bugs...
CoOLLISION 0.0.0 is at
http://www.imitidicthulhu.it/CoOLLISIONpage.html

Err..it does what?

Sorry my English is bad.
It is a quick filter,
It changes the ratio of the Sculpty and stretchs it.
All the axis get the maximum space.
In the new name of the Sculpty you find new XYZ values.
Those are the ratio for the view in world.
In this way you can to go near and over the Sculpy.
This pic I think that explains the concept better.
It was the first test.

Ahhh, okay! Got it, I think.

Very cool, I look forward to trying this out. Some builders get around this problem by making the sculpty phantom and having an invisible prim stay non phantom for seating etc. This should make that invisible prim un necessary.

Which sculpty program do you use ?

For me it looks like your sculptie program first reduces the overall resolution of your sculptie in order to keep the scales. Then your addOn program does the BBOX correction for you. But it can not return the best possible resolution.

For blender and Domino Marama's scripts (Did i ever tell, that Domino is my personal Hero? ) this problem is solved in a genius way:

you can bake in 2 ways:

1.) Keep scaling:

Render -> Bake Second Life sculpties

Then press "Keep Scale" (make the button dark green)

After clicking on "OK", the result will be similar to your test input sculptie.

pros: The sculptie rezzes in the correct scale.
cons: The SL bounding box will be wrong. The resolution of your sculptie will be reduced.


2.) Keep optimal resolution:

Render -> Bake Second Life sculpties

Keep the button defaults

After clicking on "OK", the result will be similar to your optimised output sculptie.

pros: the SL BBOX will be correct, The resolution will be best that can be.
cons: the scaling is broken, you have to manually readjust it.


Some time ago the "export to Directory" feature was added to Domino's scripts, which produces LSL code. When you open the generated LSL-script you find the scaling numbers for your sculptie. With a little fiddling you can directly apply the script to your sculptie inworld and get the scaling done automatically for you. But sadly this is not yet to be named a "userfriendly implementation".

I hope, that i did not completly missunderstand your solution and you aim for something different.

I don't think so. The sculptie will always have a rectangular BBOX even with Soldatino's trick. The problem raises when your sculptie shape differs from the rectangular shape, which is almost ever so And as i mentioned in my first answer, Soldatino's BBOX problem comes from the fact, that somehow he uses a scale preserving method to create his sculpties, which reduces overall resolution ...

As an example where you still need phantom:
Suppoose you want to sit in the canoe as one would sit in a canoe, 90 degrees rotated compared to the pic on soldatino's homepage It won't work without making the canoe phantom and add invisible seats. ok, ok i know, you would not sit, but kneel in a canoe

I thought they had the bounding box of whatever stitching type they use? I know that most of my sculpties (Which are left as spherical stitching) have a round bounding box, at least.

You are right, i was wrong and very imprecise

I was talking about the BBOX, where i should have talked about the collisionbox! And you are right, the collision box is connected to the stitching type. so it is either a cylinder, a torus or a sphere. I don't know if the collisionbox of a plane sculptie is a plane, but probablyso ....

But still the BBOX of any object is a rectangular shape. Quite irrelevant though here ... Apologize for the confusion!

Just tested aaaannndd... it's odd. It seems to be a rather oblong shape, actually. Along the two longer sides of my sculpt (It basically fills it's bounding box, so I mean the prim is stretched), it seems to me cubic, however if I walk toward the end I can walk through the prim at the corners as if it was rounded.

However, that's the only area I can walk through, just the very corners.

hi, I was far from my pc
my english is poor and I don't konw if I understand all

1) the resolution does not lose, or lose a very little value, because the streatch is first MUL then DIV.
Your Sculpty in Second Life has the values on axis enlarged, the approssimation is under the 1/256. If you have a loss example iI thank you if you let me to know it.

2) the borders most external border of the sculpty became near to the maxim value.

So, I cannot to go INTO the sculpty if it is has pits, but the limits are the major protuberance for each board ( x, y, z, -x, -y, -z).



If you have a wall ( the my above is wood) and it is 1x10 (h is ininfluence in this case) you have a bound 10x10, with my tool is 1x10.
If you have a Sculpy that has a bad result I aprecciate if I can to check the file.
I have many difficults to explain, my English is bad.
The best way is to show some examples.

_it seems to me cubic_

Part of the filename proposed by CoOLLISION has the ratio for the x y z values.
You have to adiust the sizes X Y Z in SL, resizing along the axis with those suggested proportions, or multiple.
I dont understand if you have made this setting.

oh, how bad, now i have completely confused myself lol.

the collision box of sculpties is spherical for spheres and cylinders. i don't know what it is for
torus (probably spherical too) and plane (no slightest idea by now).

For spheres and cylinders of course the collision box follows the scaling...
I should have tested that beforehand

yes but starts from 0 and ends at 255
if your scuply starts at 10 and ends at 230 the collision box is oversized
in irregular shapes it is really bigger
SL uses alway 0-255 for x, y, z
Ii is not ok for me, this is the reason of my work.

My tool first centers the shape at 128,128,128, sooner it stretchs all the borders to 0 and 255
and saving says the values on xys for each stretch
for your reverse settings in SL world

The loss of resolution does not take place in your program. You allready have reduced resolution in your input map. Here is an examle:



You see 2 spheres.
the left one is a sculptie, which was generated with maximum resolution.

I made another sphere which is about 20% of the size of the first one. Then i exported this with "keep scaling", so that it comes out as a "small sphere" in the SL viewer and with the collisionbox problems as you report. Now if i would feed the small sphere into your program, what comes out is what you see on the right side.

And here are the associated sculptie maps:



Your can clearly see, that the right one is rather limitted in color space, hence resolution...

Again: I do not blame your conversion program. It can't make the resolution better than what it gets as input. All i say is, that you should render directly with a cubic boundingbox (aka full color space in all dimensions) . Then your resolution is best.

The collision envelope of a sculpty is a spheroid with diameters half the size of the bounding box.

Rescaling the sculpty to the bounding box should be done before converting it to a texture, not after. If you're making a sculpty for application to a megaprim you probably don't want to do it at all.

The living example is just ready on page 1 of this thread

_I do not blame your conversion program_
Don't warry, I like to know what is not good
About your test
I am unable to understand
A little sphere has always few vertexs, if it has many vertexs it is a big shere, but resized in SL.
Why I dont think to loss resolution?
if I have a point , IE 12, 15, 10 to get the border it became 255, 255,255

It was resized using 127 because I need -128 ----- + 127

12 * 10.583333 = 127 int
15 * 08.46 = 127 int
11 * 11.55 = 127 int

then reverse (X axis, the first only...)

1 / 10.583333 = 0.09....

in world, using 0.09

127(the SL 0.5) * 0.09 = 11.43 ----> int 11
but 11 <> 12 !!

meaning, I can to loss 1 value of 255, what I wrote in my previous post.
But in your spheres the problem is not the loss is the resolution...

I want to check better my source. I want have only 2 decimal in the filename because the job is quick, and I hope using CINT or ROUND instead of INT for positive and negative values in my code I can to find better values to resize...
Anyway thanks

I do not see, where you do that, so there is no need for any apologize from you. It is more me to apologize for not fully understanding, what you are describing.


So again in my honest opinion your program is not the cause of trouble. The problem comes from the tool, which creates the textures in first place. There you loose the resolution. I think, that tool should allready export your work with the cubic bounding box and tell you the scaling factors.

ok, i admit, that my example was extreme, but it was only to show the effect "in its worst case". Anyways, either i do not understand, what you are really after, or i do not understand a very basic thing about oblong sculpties, which well may be the case after all.

One last thing: I tried to translate one of my sculpties through your program but i ended in something very weird:



The orriginal texture works correct (it is a 32*32 pixel map generated by Domino's scripts out of blender and it displays as expected in world). The translated pic is completely scrumbled. It is maybe, because you make an assumption on the input, which is not general enough ?

One thing maybe: The input texture is allready bounded to a cubic BBOX. Maybe that is something, you did not take care about yet ?

Another thing: What does your program do if i feed it with a texture, that your program itself has generated before? despite the fact that it is not a usefull operation, Will that cause any problems?

Argh!
I captured your pic, I resized in 128x128 and loaded it.
This is a sphere, some points lost by text lol
Anyway I think
1) Your original TGA is compressed type
or
2) your original TGA has 32 bit instead of 24
Excuse me, my vers. is the first, 0.0.0., now I write the controls for not allowed TGA :|
I hope for 1) or 2), differently it is a bug, I thank you very much if I can to check the original file!

ps If it has already the bounding box it is not a problem, I checked cubes 255x255x255.
for :
What does your program do if i feed it with a texture, that your program itself has generated before?
Nothing, it should generate the same texture.



*EDIT: Ok, I uploaded now the version 0.0.0d.
Alert if TGA file type is not allowed.
Allowed TGA are uncompressed, no-comment in the header (rare), and 24 bits colors (no alpha channel).

Ok, I wrote again the part of resizing, with a different algorithm, in order to have fewer division. It has also notices the processes item.
The current version is 0.0.0e



4 + 1 (canoa) prims