to make bbox check fast enough you have to sort all your pieces or place them in the grid (see my posts about this matter on this forum). in the other case it would be too slow because you have to check every piece against each other.
So either solution is rather slow and cumbersome, in other words your suggesting that any intersection check is going to be slow. As a result recommending that I just leave it as it without it?
i think the grid method has to work well. the environment that you show in your samples with random intersections will look bad. so i vote for the ‘intersection pre-detection’.
(try to find my post and code sample about “get all intersected nodes”)
this the snippet?
http://forums.cgsociety.org/showpost.php?p=7032076&postcount=23
actually, what am i talking about? there is a voxel based theory of collision detection. i’m a big fun of it. being persistent you could find my US patent about this matter.
it’s the good one. but i remember some other.
That sounds pretty slick. I’m probably not going to dive into any patent stuff and all that. I’ll probably surf around a bit and see what i can come up with or find.
Maybe I’ll look into some sort of grid like system.
Just out of curiosity why not shoot a ray, the length of the new pipe. out from the previous objects z axis and see if it collides with any object? And do that sort of checking?
Is that not reliable or fast?
Well on a side note, where would I, in the case of my tool, add an undo function that wouldn’t crash max?
don’t worry about a patent. mine was expired 6 years ago (math algorithms don’t live long).
raytrace… well. you probably can check any next enabled move by using the ray. but you can’t be sure enough that the placed piece will not occupy any taken space around.
the doing your ‘steps’ with no undo will not help you anyway.
I tested out the undo and it works fine. I was weary that it may be unstable but it’s fine.
hmm…I’m just not sure which direction to go with the intersection methods we’ve discussed.
I understand what you’re saying about the raytrace method. It has it’s inaccurate results, which thinking about it, is not the end of the world either because the users can easily just rotate or undo and continue about their way.
but the ray method just like the node’s bb has be check with every object in the scene.
your enemy is the memory leaking. don’t trust a max experts who say that any taken by mxs memory will be returned automatically. ones lost memory will be never returned complete!
yours bottleneck is the ‘clone’ function. it leaks badly. try to trace steps. and you will see how the tool eats itself.
i think that ~2-3 hundred pieces is an actual limit for your tool right now.
for any ‘generic’ algorithm the limit has to be ~10k at least