if they are just static entities I think setCullHint maybe more efficient
I think that in my case, the more efficient solution is GeometryBatchFactory.
The sixth post one the first page on this thread had an explanation of DOT product for getting a relative distance to a spatial in front of you (the dot product being positive).
I had a look on the web for more explanation regarding this in the context of distances etc but really didn’t find much that elucidated the issue.
Are there any good write-ups that can shed some light on the subject with regard to use in a 3D scene graph context?
I really don’t want to read dozens of texts to get a handle on this like I had to do for quaternions : P
I kind of explained it before but here is a picture from wikipedia… we’ll see if it shows up.
(it’s from this page: http://en.wikipedia.org/wiki/Dot_product)
The implication here is that if a and b are both unit vectors then the dot product will be the cosine of the angle between them. Or, if you were to draw a right angle from a to b, the dot product is the length of the side of the triangle on a… which is the cosine.
So if b is not a unit vector then the whole thing is multiplied by b’s length. Triangles are such that if you scale up one side then all of the other sides also scale… basic trig. Therefore, the dot product ends up being the length of the base of a triangle whose hypotenuse is b… and the base will be coincident with a.
Please forgive my crude drawing:
This is not a pure distance but it is a very important one… and in camera space can be way more important than a regular distance.
1 Like
This is the bit that interests me …
... and in camera space can be way more important than a regular distance.
I can't picture what significance this would have. Any light?
I said that already, too.
At the edges of the screen, objects are farther away using regular distance than they are using the dot product. So if you use regular distance for turning things on and off then they pop in and out as you turn… which can be a bit jarring.
Yes, you probably said it and your capacity to explain is very good, but my capacity to comprehend is somewhat lacking perhaps. But let’s see if I’ve got a handle on it now …
So, if my camera is looking in the -Z direction, I’ll have a unit vector of (0, 0, -1) for the camera direction.
And I have a tree standing at (-3, 0, -4), so this will be in my camera’s forward view (being -Z) and off to the left (being -X).
The dot product between camera and tree is: (0 * -3) + (0 * 0) + (-1 * -4) = 0 + 0 + 4 = 4
It’s positive so it is in front of the camera.
Plotting these two vectors, both from the origin, will seem to give the idea that the dot product projects a plane along the Y axis, but perpendicular to the Z axis right where the tree is. This means that culling with a dot product will include any geometry between the camera and the tree, that is, anything in the interval where 0 < Z < 4. Anything on the farther side of the plane is culled.
This would seem to be cool in that it would not matter where the camera is pointing, since that perpendicular plane would follow it and cull as per the “inside or outside” criteria.
Is this analysis correct?
1 Like
Yeah, that’s right.
I was trying out the following code just as wezrule and madjack suggested:
[java]
cam.setFrustumFar(100);
setup.shootables.setCullHint(Spatial.CullHint.Never);[/java]
However, everything is getting culled. Any help?
@memonick said:
I was trying out the following code just as wezrule and madjack suggested:
[java]
cam.setFrustumFar(100);
setup.shootables.setCullHint(Spatial.CullHint.Never);[/java]
However, everything is getting culled. Any help?
The problem with that approach is that the far frustum does more than just control camera-space clipping. It actually prevents triangles from being drawn farther away than 100. Just like things won't be drawn closer than the near plane... they get cut.
1 Like
I was trying to use that because I think it’s faster. Will try to think of a different approach. Thanks pspeed.