pivot point

[Phideas]

Good evening to all !!!!! i need some help, how to change pivot point from center  to on other point  ( I use 3ds max ) just need to animate 1 door

 

[Rolig Loon]

Look at the first entry in this sticky thread

 

[animats]

Chin Rey and I recently discovered that #2, "including a small, transparent piece that is offset on one side of the door's hinge edge", breaks llCastRay. Ray casts through such objects randomly go through it. I ran into this with a large semitrailer truck my NPCs couldn't see. Got that down to a dummy semitrailer physics model with strange cast ray problems. Had others with scanners over to check it out. Found out that three tiny triangles to make the physics and visible models match caused a problem. Rey gave me a door with an offset extra vertex to try, and it has the same llCastRay problem in an even simpler situation. My NPCs will walk through it, but an avatar gets a collision. Haven't gotten to the bottom of this yet.

[Beq Janus]

 

3 hours ago, animats said:

Chin Rey and I recently discovered that #2, "including a small, transparent piece that is offset on one side of the door's hinge edge", breaks llCastRay. Ray casts through such objects randomly go through it. I ran into this with a large semitrailer truck my NPCs couldn't see. Got that down to a dummy semitrailer physics model with strange cast ray problems. Had others with scanners over to check it out. Found out that three tiny triangles to make the physics and visible models match caused a problem. Rey gave me a door with an offset extra vertex to try, and it has the same llCastRay problem in an even simpler situation. My NPCs will walk through it, but an avatar gets a collision. Haven't gotten to the bottom of this yet.

I would expect that this is basically the same problem as the "When I rez on mesh my stuff gets lost" problem. It is a viewer/server interaction problem. I don't have an answer that fully explains an llCastRay fail but it is probably related. Here is the issue that I suspect you get.

When the viewer attempts to place items, and I suspect when the viewer tries to position the avatar, it first uses visual space to estimate a collision, There is a "visual" ray cast that will collide with an object based on its appearance, With a visual collision detected, the viewer calculates the entry point and angle of entry into the object's bounding box. This is sent to the server side for a physics ray cast against that object alone. If the physics shape does not correspond with the visual collision then the physics raycast fails to "land", the raycast fails and in the case of rezzing items it basically just drops the ball. By the sound of it, with avatar movement it just blocks. Speculation and interpolation based on what you mentioned but it sounds too similar to be unrelated to this.

[animats]

1 hour ago, Beq Janus said:

It is a viewer/server interaction problem.

It happens even when a prim is doing the ray casting. A simple prim with a script that casts rays the direction the prim is pointed can reproduce the problem. My NPCs are all server side, too; they're animesh making llCastRay calls.

Someone was over at my workshop with a ray caster that builds up an image using large numbers of llCastRay calls, and they imaged the truck trailer as something with holes in it. I thought it was Wulfie Reanimator's device, because he was there at the time, but apparently not. Who has that tool? Need to try it on the simpler door case. The trailer was complicated; we were looking for inside/outside problems, reversed normals, etc., and we were all puzzled. The door is a flat object. Need a clean enough case to file a JIRA.

[Wulfie Reanimator]

6 hours ago, animats said:

It happens even when a prim is doing the ray casting. A simple prim with a script that casts rays the direction the prim is pointed can reproduce the problem. My NPCs are all server side, too; they're animesh making llCastRay calls.

Someone was over at my workshop with a ray caster that builds up an image using large numbers of llCastRay calls, and they imaged the truck trailer as something with holes in it. I thought it was Wulfie Reanimator's device, because he was there at the time, but apparently not. Who has that tool? Need to try it on the simpler door case. The trailer was complicated; we were looking for inside/outside problems, reversed normals, etc., and we were all puzzled. The door is a flat object. Need a clean enough case to file a JIRA.

It was @Fenix Eldritch with the raytracer. It displayed a completely random pattern where the mesh surface should've been.

Didn't the trailer we were puzzled by use loose verts to adjust the physics shape, instead of triangles?

[Beq Janus]

Interesting, I think I misread your meaning before, it sounded like NPCs were able to walk through but avatars were not. How does the viewer display the trailer in physics view? The viewer simply draws a mesh dervied form the physics shape data so it will show what "should be" the collision surface as opposed to what the server is "actually" seeing. I wonder how the server performs the raycast, maybe it has some weird two phase casting like that of the viewer?

Verts to pad the physics might cause issues, I can kinda see how that might be an issue (maybe), but in no case would you expect holes where no holes should be. 

That said llCastRay is phenomenally inaccurate. I remember using a scanner (I think it was part of the sculpt studio product) to test something and the accuracy was very low resolution, I never pursued that, so I can't say whether it was the tool or llCastRay itself.

[Wulfie Reanimator]

2 hours ago, Beq Janus said:

That said llCastRay is phenomenally inaccurate. I remember using a scanner (I think it was part of the sculpt studio product) to test something and the accuracy was very low resolution, I never pursued that, so I can't say whether it was the tool or llCastRay itself.

It must have been sculpt studio. llCastRay is very accurate, I can't imagine its accuracy being any worse than regular floating point rounding errors.

For example, here's a gap between two 0.1 cubes, and llCastRay is able to fit right between them. This is a simple visualizer I've scripted myself:

[animats]

9 hours ago, Wulfie Reanimator said:

It was @Fenix Eldritch with the raytracer. It displayed a completely random pattern where the mesh surface should've been.

Didn't the trailer we were puzzled by use loose verts to adjust the physics shape, instead of triangles?

Thanks. Messaged Fenix. The trailer has three very tiny triangles, not loose vertices.  I got the COLLADA model for its physics model from the creator, and if I zoom in close enough, they are triangles. Within SL, you can't zoom in that close, so they look like vertices.

[animats]

After an hour over at Fenix's workshop doing ray casting tests, we're both still puzzled. Something obscure goes wrong with loose triangles and the physics model. For Chin's door, the door becomes totally see-through to ray casts while being solid for collisions. For the GEMC trailer, it becomes partly see-through in a noisy way, with some ray casts going through and some not. That's really strange. Loose triangles and prim physics bring out some bug.

For the simple pivoting door, here's a possible best practice to avoid problems.

Basic door.

• Create the door.
• Create or use a small mesh cube, as shown, one door width from the pivot point
• Link the two, with the door as the root.
• Set the extra cube to "Physics model: none", "Texture: none", and "Transparency: 100%".

This moves the pivot point to where you want it. This is only one LI, because mesh accounting lets you link two simple mesh objects at one LI. Now you have a basic door without trying to exploit undefined behavior in the uploader.

It's two prims, though, so you can't link it to a linkset and still have the door work.

 

[ChinRey]

On 4/7/2020 at 10:16 PM, animats said:

Rey gave me a door with an offset extra vertex to try, and it has the same llCastRay problem in an even simpler situation.

No, it was a door with a balancing triangle, not a loose vertice. I haven't really checke this but I believe doors using the loose vertice solution dont' suffer from this.

 

23 hours ago, Beq Janus said:

I would expect that this is basically the same problem as the "When I rez on mesh my stuff gets lost" problem. It is a viewer/server interaction problem. I don't have an answer that fully explains an llCastRay fail but it is probably related.

Apparently the uploader's physics model analyzer really only works with source meshes made from clearly defined complete convex hulls. We get the ray casting issue if the source contains hulls without all surfaces defined or a combination hulls and triangles. What obviously happens, is that the code doing ray casting and the code doing collision detection handle these models differently.

We can usually fix the problem with incomplete hulls by switching from Surface to Solid but I don't really trust that solution and I don't even know if it works with source meshes that have a combination of hulls and triangles.

I think I'll be going for loose vertices to adjust pivot point from now on. It's an unsupported feature so there's no guarantee it won't stop working some time in the future but it's so ar buried in the mesh code, they'd have to rewrite it all from scratch for it to go away. The alternative is to use a cube rather than a triangle to balance the physics model. (You can stil use a single balancing triangle for the visuals btw, that's completely separate from the physics.)

Edited April 8, 2020 by ChinRey

[Beq Janus]

On 4/9/2020 at 12:12 AM, ChinRey said:

Apparently the uploader's physics model analyzer really only works with source meshes made from clearly defined complete convex hulls. We get the ray casting issue if the source contains hulls without all surfaces defined or a combination hulls and triangles. What obviously happens, is that the code doing ray casting and the code doing collision detection handle these models differently.

I'm not 100% clear on what you are saying here.

We do know that havok prefers hulls to triangles and thus an analysed physics comprised of hulls is more resilient than a non-analysed mesh physics. For example, you can ghost through a mesh physics wall easier than a hull physics wall. That is a problem of velocity and sim/physics frame rate as much as anything (I believe). A mesh physics has no sense of thickness, it has triangles that may be arranged as a box (or whatever) but whereas a hull IS a box, and anything inside the box is still a collision, with a mesh you can be "inside" due to the rounding/lag and not show as a collision.

I am not sure what "hull without all surfaces defined" means can you explain? In my head, a hull is by definition is a closure around a set of points. In mesh analysis these closures may be grouped together to form a non-convex overall shape. In the case of the door. It should just be a hull for the door cuboid and a hull for the padding. 

The assertion that a single vertex is not problematic is intriguing.

I raised this in a meeting on Wednesday with @Rider Linden who would dearly love to see a Jira for this so that he can take a proper look. In the meantime I think I might go play in aditi and see what some of my doors do as I am pretty sure I use triangles.

 

[Wulfie Reanimator]

24 minutes ago, Beq Janus said:

A mesh physics has no sense of thickness, it has triangles that may be arranged as a box (or whatever) but whereas a hull IS a box

I'm pretty sure there is no distinction between "mesh shaped like a box" and "a hull." Like you said:

25 minutes ago, Beq Janus said:

a hull is by definition is a closure around a set of points

Mesh isn't any different from prims, essentially. It is equally easy to phase through prim walls as it is mesh walls, assuming the walls are "water tight" solid shapes instead of disconnected planes. For example, if you used these as the physics model:

This works as anyone should expect (you cannot phase through the surface into the box), it's a hull, the physics engine will force you out of the box if you are in it:

This has 5 walls with practically no thickness, it's not a hull, and here the collisions are unpredictable and you can often walk out of it even at very slow speeds, you can even "climb" the edges of the individual triangles:

This also works as you'd expect, it's a hull, just concave (the hole doesn't go all the way through, but it would still be a hull):

This has the same problems as before, except you can also get stuck between the planes:

All this said, I haven't been able to repro the raycasting issue myself. I've uploaded some simple shapes with loose verts but they seem to work fine. Even the last picture above.

[MaxMare]

Edit: I seem to have misunderstood...thought you`re asking in Max

I bought quite a few door scripts as I can`t do it my self and in the end the best thing I found was Kool Door script, it works without hinge and for any type of door, cupboard etc...in case you get frustrated trying to do it yourself 

Edited April 10, 2020 by MaxMare

[ChinRey]

8 hours ago, Beq Janus said:

I'm not 100% clear on what you are saying here.

Well, it wasn't 100% clearly explained but I tried my best.

Maybe a few pictures will help.

This is a basic hull, just like Wulfie's:

You can run it through the physics analyzer with no problems. That is you can't really walk on it - you'll always hover a little bit above a hull - but raycasting works just fine.

This is a cube with one face removed:

If you run it through the physics analyzer, it will fill in the missing surface and create the same hull as in the first picture except with one very curious flaw: It works perfectly fine as a collision body but for some reason it doesn't show up with raycasting. It doesn't matter which face is missing from the original, the entire hull becomes "invisible" to the ray.

This is a physics shape made from two bodies, one cube and one triangle:

In theory the physics analyzer should handle the two bodies separately, defining the cube as a hull and the triangle as ... well as a triangle. However, according to what Animats have uncovered, that is not the case. There is some sort of intereference between the two causing the hull to have the same "raycast invisiblity" as the one in picture no. 2.

Possibly (although I'm not at all sure) related to this, is the other main problem with the analyzer.

Here are two hulls close enough to touch each other. Both are complete cubes with all six faces:

When you feed something like this through the analyzer, it will not treat those two as separate hulls even though they are cleary defined as such. Instead it will merge them into a single concave hull and then try to split it up into multiple convex ones with rather unpredictable results. There's a very simple way around it (I think it was @Aquila Kytori who discovered it long ago): keep a tiny fraction of space between the hulls to force the analyzer to handle them separately. All reasonably experienced mesh makers know Aquila's solution so except for some very rare extreme cases, we hardly ever have any problems with it. It can cause inexperienced mesh makers a lot of gray hairs though.

[ChinRey]

On 4/7/2020 at 9:38 PM, Phideas said:

Good evening to all !!!!! i need some help, how to change pivot point from center  to on other point  ( I use 3ds max ) just need to animate 1 door

We're heading off topic fast and the OP's question hasn't been properly answered yet.

The pivot point of an SL object is always right at the center of its bounding box. There's nothing we can do about that but there are two basic ways to work around it.

One is the scripting solution Rolig suggested. What those scripts do, is calculate the deviation for each step in the door's rotation and then move the door to compensate.

The other solution is to extend the bounding box. Traditionally this is done by adding a single triangle positioned so the center of the bounding box ends up right at the hinge edge of the door itself:

Give that triangle its own material face, make it 100% transparent after you've uploaded and you have a mesh door the way it has been made by good mesh door makers for many years and it has worked fine until now.

But it now turns out that this solution may be a problem for animesh characters. Animesh characters don't see the world the same way we do. They use something caleld "raycasting" to spot objects around them and it turns out that for some weird reason nbody can explain yet doors made that way are invisible to raycasting.

[ChinRey]

10 hours ago, Wulfie Reanimator said:

Mesh isn't any different from prims, essentially.

That's not quite true. There are hulls and then there are hulls.

In addition to the generic convex hull, HAVOK also supports four predefined simple ones (sphere, cube, capsule and cylinder) that it handles far more efficiently than the generic ones. According to the physics weight formula, which seems to be fairly accurate here, a cube handled as a generic hull is six times as heavy as one handled as the predefined cube physics shape. The difference for a sphere is much, much higher.

Prims use those more efficient predefined hulls whenever possible, that's how they often manage to keep such low physics weight. We don't have access them for meshes though, so their physics are always defined as generic hulls and/or triangles/triangle lists.

 

10 hours ago, Wulfie Reanimator said:

I've uploaded some simple shapes with loose verts but they seem to work fine.

I suppose I have to repeat what I said in a previous post then. The door I gave Animats, was made the traditional way with a balancing triangle, not with a loose vertice.

SInce your tests with loose vertices are positive, I suppose that is one possible solution to the problem. I do have two minor reservations though. One is that most SL mesh makers have fairly limited technical skills and knowledge so they may not be able to handle loose vertices safely. The other is that loose vertices were not supposed to exist in SL at all. It's a side effect of how SL's mesh parser works and although it's extremely unlikely, there's always the possibiity that it will be broken by an update some time in the distant future.

Edited April 10, 2020 by ChinRey

[animats]

9 hours ago, ChinRey said:

The other is that loose vertices were not supposed to exist in SL at all.

Right. That's relying on undefined behavior. It might break someday if the mesh uploader gets its badly needed overhaul.

 

[animats]

Here's an image from the ray casting issue. This is what Fenix and I got over at his workshop, where he has a setup to make large numbers of ray casts and produce an image.

 

Difficult object in Fenix's workshop

The object being scanned is the grey thing in the center. The scanner is up and to the right, and the checkerboard floor and purple wall are just there for backdrops.

What's being scanned is a shrunken version of the physics model of a a semitrailer. The original problem was with a rather nice truck. Here, we have just the physics model of the truck, uploaded as an object of its own and reduced in size. Same problems as the full truck, but in a simpler test case. This object has three loose triangles and was uploaded in "surface" mode. If those triangles are removed, or it's uploaded in "solid" mode, no problems.

The image on the "screen" was built up from thousands of llCastRay calls. That area of black and green pixels is just wrong. Some ray casts go through, some get hits. No idea why. On most objects, the scanner produces a good scan of the physics model. It doesn't see Chin's door at all.

The trailer object isn't broken. I have the COLLADA file, and have looked at it in Blender in detail. All the normals face in the correct direction. All the walls of the trailer have an inside and an outside, and are at least 0.100m thick. It's very simple; about one page of COLLADA.

There it is. Everyone who's looked at this is puzzled.

I suspect that whatever makes the loose triangle/vertex trick work is really a bug. This kind of flaky behavior suggests it's more of a bug than a misfeature.

[ChinRey]

5 hours ago, animats said:

Right. That's relying on undefined behavior. It might break someday if the mesh uploader gets its badly needed overhaul.

Is there any possibility that would affect meshes that have already been uploaded?

 

4 hours ago, animats said:

This object has three loose triangles and was uploaded in "surface" mode. If those triangles are removed, or it's uploaded in "solid" mode, no problem

I'm inclined to apply my Six Dark Years theorem ("Any decision made by Linden Lab from 2008 to 2013 is assumed to be wrong until proven otherwise") here even though this is supposed to be code they bought from HAVOK, not something they cooked up themselves. The Surface method is the default so it's likely there's something wrong with it. Has anybody ever had any of these ray casting problems with physics analzed with the Solid method?