[1.1B1 BUG] raycasting with collidable forest brush objects is broken - RESOLVED

#1 More info -- this is a Forest bug

We are using a .DAE model Tree and a Rock both use a single cube collision mesh and players seem to collide with them fine in forest brush mode or static placement.

It looks like the collisions do not even work right on some raycasts but others do! Sometimes raycasts go right through collision meshes when the objects are part of forests.

Here are examples of links in astar go right through when the object should stop the link, but other links are broken

Right click, View Image to view full images




Here is the same DAE placed as a static and set to Collision mesh. You can see exactly how it should look if the collisions on forest items worked.



And finally, here you can see the static placed DAE with Collision Mesh used and perfect broken nodes (Shown in red)



If anyone has a solution for this please advise, we are kind of DOA without this piece working.


And for reference here is how I am doing my collision.

gServerContainer.castRay(Src, Dst, STATIC_COLLISION_MASK, &rInfo)

This also happens when the forest is running on a dedicated server and collisions happen

#2 bump - can the QA team confirm this bug will be fixed in 1.1B2 -- this is quite important.

#3 For QA we can provide a piece of source code and level including assets to replicate this bug.

Just email termls1@gmail.com if you want this put together.

#4 I think the problem is, this is not actually a T3D bug.

Every one of my castRay functions seems to be working perfect, but im not using it as exhaustive as your navigation mesh looks like IT is.

If there were a bug with gServerContainer.castRay I expect more T3d users would be able to confirm and collaborate with you about it.

#5 Are you using collision meshes with forest brushes?

That is where the bug is, the same objects placed as statics with collision meshes work 100% perfect, add it to a brush and brush it on then raycast with it.

#6 Ah, yes i had just finished re-read your messages over to see if i had missed something, and then went to test with forest brushes just to see, and- well T3D isnt going to run until i reboot the computer(some very old odd bug I can not find enough details about to compile a bug report about, and no one else seems to have so i figure its my odd hardware configuration); and i have all my work files open so a reboot right now is not convenient.
I will test forest brushes with my castRay functions and see if i get the same results, once i am able to reboot...


But i might suggest a more complete bug report so when QA arrives, they have no trouble knowing what your taking about.

#7 What do you mean more complete report? I offered to give source code and a level to QA that will replace this issue 100% of the time. Also it should be easy to confirm with a simple brushed on collision mesh and ray cast that it is totally broken.

I believe this is probably fixed in SVN I just want to have QA test and confirm it as its a huge issue for us.

Its probably a huge issue for lots of other people too they just don't know it yet because they have not got that far.

#8 It is just that i myself did find it hard to see what your 'bug' was.

And the fact that I know the player and projectiles collision with the forest brushes DO work just fine, and they both also use a raycast.

Im quite sure QA will never truly have the time to test a per-instances of quirky bugs, thats not a reasonable use of there time. But according to Scotts blog post, a well constructed bug report will expediat the process.

#9 I'm not sure what you are confused about or why your even posting here when you have not done any testing or don't understand the problem and you offer no suggestions.

Also it seems like you might not have enough of a understanding of the internals of the engine to be constructive.

I can assure you the bug exists and happens 100% of the time.

If you have anything constructive to add feel free, otherwise I would like to have QA add this to their list.

#10 I am sorry my attempts to be helpful to you have only added to your frustration and rewarded my efforts with a face full of Cold Pricklies.

Before constructing this reply, i took the time to re-boot, ran T3D and tested the functions i have made to handle my raycast requirements. My raycast succeed all of the time on all objects i could think to test them.

Quote:I'm not sure what you are confused about

I mentioned above that i did not think this is a bug, and offer the logical reason i think it is not a bug.

Quote: or why your even posting here when you have not done any testing

Yes, i am sorry, I did not do any testing at post #4, and explained my sorrow for misunderstanding your 'bug' in post #6. But now i have done the tests and my results match my original hypothesis.

Quote: or don't understand the problem and you offer no suggestions.

I have made some suggestions, and proposed the idea that perhaps your bug report is not as clearly detailed as it could be for the sake of understanding your problem to the fullest one is capable of.

I did have a short list of other things that could possible be contributing to your 'bug', but simply was seeking more details before posting my ideas.

Once more, I am sorry you are unable to comprehend my attempts to be helpful to you.

EDIT:

Quote:
Also it seems like you might not have enough of a understanding of the internals of the engine to be constructive.

I do not see where you may have collected enough evidence about my understanding of the internals of the engine, to support this statement.

#11 Ok I just made a new test environment with a collision mesh rock

This rock has a square collision mesh inside it and should collide as if you were running into a cube shape

On my test level I have one rock placed as a STATIC (Col mesh) and one rock that is a member of a Forest brush.

When collisions intersect with the forest rock it takes a LOT of time

Here is a static rock being hit by the nav mesh discovery system

Discover : 46.800000% in 31
Discover : 46.900000% in 63
Discover : 47.000000% in 110
Discover : 47.100000% in 171
Discover : 47.200000% in 125
Discover : 47.300000% in 109
Discover : 47.400000% in 93

And here is where we hit the forest brushed rock, notice how long it takes to interact with this object.

Discover : 50.300000% in 94
Discover : 50.400000% in 296
Discover : 50.500000% in 2620
Discover : 50.600000% in 2293
Discover : 50.700000% in 234
Discover : 50.800000% in 78

And now here is a picture showing how flat the top of the collision box is on a static object, notice how everything is flat and even, you can see the green lines are easy to walk on and red lines indicate harder to walk on so in this case the surface is fairly flat with a edge that is avoided by AI.


Now the same rock painted with a Forest brush top view. You can see in this image the top of the rock is not flat at all as if the collision mesh is deformed or the forest system is mixing the visible mesh with the collisions somehow, or its just broken in some other way maybe related to LOD or deformation.


These two different images should be solid proof that the collisions are broken, but I double checked collisions on the XY plane also, here is the rock showing the proper collisions and how they are discovered. It is very easy to see the shape of the collision mesh in this image, the more red a line looks the closer a node was to a surface that is not recommended for AI like a solid wall, in this case we are perfect.



And now the brushed on forest rock, as you can see there are lots of red lines that indicate this area is not good for walking, but we get links here in many places where the lines are passing right through the collision mesh, also there are broken links like there should be in some places indicating that collisions DO happen, they are just not correct.


Just because one single ray cast causes a collision does not mean that there is no bug, and because your player can collide with something does not mean much either. In most cases my player seems to collide with this stuff fine, it seems like the player actually works 100% and this could be a issue with the server ray cast.






I hope you do not take this the wrong way but it just seems like your here to discredit me or this bug when I have shown how to replicate this and provided all necessary information including great visuals of whats happening.


If you have anything else constructive to add about collisions with forest items, forest lod, collisions, etc your welcome to but please refrain from any off topic stuff as it is not helpful.


You posted "Every one of my castRay functions seems to be working perfect" or saying that this is not a valid use of the QA departments time and this is a perfect example of how not to be helpful.

If you cannot understand how this is a bug now, then just leave it alone.


Tested on Xeon and AMD processors

Verified this is broken on Client and Server castRay

#12 Yes, that is indeed a bug, your new description leaves no room to misunderstand that fact.

'Every one of my castRay functions seems to be working perfect, but im not using it as exhaustive as your navigation mesh looks like IT is.'
It is good that we both seem to agree that my common usage of the T3D functions as they are designed (player and projectiles type of collision) are NOT the same as your very clever integration of a navigation mesh.

My saying this is not actually a T3D bug, was based on the concept that a T3D bug would be because of a standard T3D function not working as standard designed. And because I am using standard T3D functions, i could not replicate any error in any collision object types, every one of my castRay functions seem to be working perfect.

I am sorry for the misunderstanding.

You indeed DO have a bug, with the way T3D reports collision details to your navigation mesh.

Your idea about it being LOD is about the only plausible cause I also can think of.

I am truly impressed with your ability to get a navigation mesh of what appear(from your example pics) to be a very high detail level of collision reports. My failed design would only test every 10 Torque units and i was trying to generate it by proximity from my AI location at run time.

#13 ContainerRaycastRendered does seem to be taking more than it's fair share of CPU time with a forestObject in-game.

Though a little hard to test fully as I don't fancy replacing half a gazzillion trees of the forestObject by hand to see what the difference would be in a perfect comparison... but minus that ForestObject (and thus the extra collisions though still the raycasts) ContainerRaycastRendered shows a 6th of the stress.

[edit]

//no forestObject
%%NSTime  %% Time  Invoke #  Name
 17.849  27.188   262680 ShapeBase_PrepRenderImage
 10.248  63.854     8906 CanvasRenderControls
  6.323  11.579     8906 StdClientProcessList_AdvanceTime
  4.888   6.553     8906 SimAdvanceTime
  4.182   4.182     8906 SwapBuffers
  3.178   3.217  6665810 ShapeBase_ProcessTick
  2.411   2.412   307313 TSMesh_CreateVBIB
  2.184   2.326   307313 TSSkinMesh_UpdateSkin
  2.087  17.379     8906 RenderPassManager_Render
  1.892   3.306  1739870 GFXDevice_updateStates
  1.799   1.824   185701 ContainerCastRayRendered//<---------------

//with forestObject

%%NSTime  %% Time  Invoke #  Name
  8.398  18.569    81086 ShapeBase_PrepRenderImage
  7.267   7.271    66818 ContainerCastRayRendered//<----------------

#14 I thought I saw a thread someplace else that talked about a bug in the forest collision, in that it always used the shape of the model rather than the collisions box.

I'll see if I can dig up that information.

Here are some possibly relevant threads:

www.torquepowered.com/community/forums/viewthread/106379
www.torquepowered.com/community/forums/viewthread/106413

#15 Eric, it does indeed look something like that on the top of the model as you can see from the image of the top of the rock.

However, forests do not collide without a collision mesh and when i slide along a surface of my rock it is using the collision mesh, not visible mesh otherwise i would get snags and bumps.

#16 @Chris
Caylo was just trying to help with his experience (and it is quite extensive when it comes to our engines). I do not think any offense was intended.

Michael Perry has posted the format for bug reports here:
http://www.torquepowered.com/community/forums/viewthread/115183

The template is for our iPhone engine, but it is currently in-use for all of our engines.

They can be posted on this forum:
http://www.torquepowered.com/community/forums/63/11561

Make sure to link to this topic as well in the report since you have gone to great lengths to provide strong visual data for this issue.

That will help the QA lab determine how best to approach the issue.

#17 ttt, no qa tag?

#18 Just to check, are you compiling the cached.dts using the 1.1b1 DAEtoDTS importer?

Because the latest DAEtoDTS is bust on positioning colmesh and bounds. The previous (1.0.1) version is fine.

#19 Logged: TQA-563

#20 MATT....keep up!!!
hope T3D next version number come fast!!!!!