AABB intersect

[Rémi Deletrain]

Hello everybody,

I try to make a code find an intersection between a ray and a box. I read a lot of thing on the internet and one of the best code I could find is this one.

def box_aabb_intersect(bbox_min, bbox_max, ray, direction):

    t1 = (bbox_min.x - ray.x) * direction.x

    t2 = (bbox_max.x - ray.x) * direction.x

    t3 = (bbox_min.y - ray.y) * direction.y

    t4 = (bbox_max.y - ray.y) * direction.y

    t5 = (bbox_min.z - ray.z) * direction.z

    t6 = (bbox_max.z - ray.z) * direction.z

    t_min = max(max(min(t1, t2), min(t3, t4)), min(t5, t6))

    t_max = min(min(max(t1, t2), max(t3, t4)), max(t5, t6))

    if t_max < 0.0 or t_min > t_max:

        return

    return t_min

Everyone says it works but I can not make it work at home. Does someone have an idea?

[Alok Gandhi]

Can you elaborate more on what is not working with your code. There are a lot of algorithms for axis aligned bounding box and ray intersections. This is a good resource for such algorithms.

Also, I see that your function is either returning `None` or some float value (t_min). Usually, the intersection algorithms return a boolean - `True` for an intersection, `False` otherwise.

The algorithm you have posted seems alright to me except that you need to return a bool. Probably this should be -

def box_aabb_intersect(bbox_min, bbox_max, ray, direction):

    t1 = (bbox_min.x - ray.x) * direction.x
    t2 = (bbox_max.x - ray.x) * direction.x
    t3 = (bbox_min.y - ray.y) * direction.y
    t4 = (bbox_max.y - ray.y) * direction.y
    t5 = (bbox_min.z - ray.z) * direction.z
    t6 = (bbox_max.z - ray.z) * direction.z

    t_min = max(max(min(t1, t2), min(t3, t4)), min(t5, t6))
    t_max = min(min(max(t1, t2), max(t3, t4)), max(t5, t6))

    return t_max >= t_min

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/18ab0a86-841b-4390-9999-b23b51665012%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

[Rémi Deletrain]

Thank you for your answer Alok,

After much rereading and viewing other script on the internet I saw my error ... you have to replace the * by / for each "edge" ...

I have only one condition that tells me whether I have an intersection or not. In this case I return None. The script that will call this function will have to make the verification namely: If it's none I do what? This is not None so I have the min, max values ​​of my intersection

def box_aabb_intersect(self, m_bbox):

        """
        !@Brief Check if ray intersect boundingBox.

        @type m_bbox: OpenMaya.MBoundingBox
        @param m_bbox: BoundingBox you want to check

        @rtype: float
        @return: Distance of ray origin and intersect point.
        """

        t1 = (m_bbox.min().x - self.__v_origin.x) / self.__v_direction.x
        t2 = (m_bbox.max().x - self.__v_origin.x) / self.__v_direction.x
        t3 = (m_bbox.min().y - self.__v_origin.y) / self.__v_direction.y
        t4 = (m_bbox.max().y - self.__v_origin.y) / self.__v_direction.y
        t5 = (m_bbox.min().z - self.__v_origin.z) / self.__v_direction.z
        t6 = (m_bbox.max().z - self.__v_origin.z) / self.__v_direction.z

        t_min = max(max(min(t1, t2), min(t3, t4)), min(t5, t6))

        t_max = min(min(max(t1, t2), max(t3, t4)), max(t5, t6))

        #   if tmax < 0, ray (line) is intersecting AABB, but the whole AABB is behind us
        #   if tmin > tmax, ray doesn't intersect AABB

        if t_max < 0.0 or t_min > t_max:
            return

        return t_min, t_max

[Alok Gandhi]

Ok got you. Good to know that you figured it. Just a quick note about your implementation specific to python. It is better not to have attribute starting with __ if you want to those attributes that attribute to be subclassed. Python interpreter does a name mangling for attributes starting with __ so that if class Foo has an attribute __bar, it would always refer to the Foo__bar and subclasses cannot override it. If a subclass Baz(Foo) tries to override __bar, it is simply not allowed.

In your example code, I see that you have __v_origin.x being used. That means __v_origin.x cannot be subclassed. If your intended purpose is such, then you are on the right path, if not then you need to name it _v_origin instead of __v_origin.

--
You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/91e425ff-e687-41a0-a5f7-8e3a449aabeb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Rémi Deletrain]

Thank you for your comment,

This function is in a class. There are private variables and that are called with:

    - self.origin()

    - self.set_origin()

    - self.direction

    - etc.

That seems correct to you ?

I got into the habit of doing that but I may be wrong...

[Alok Gandhi]

That seems correct to you ?
I got into the habit of doing that but I may be wrong...

It is absolutely fine to use single underscores for attributes that are called internally. I was only saying that using double underscores instead of single ones, will make the attributes 'protected' in the sense that any subclasses will not be able to override them. In your case, if you are not subclassing those attributes (or maybe you are not subclassing at all) then it is fine to use _. But, if you are subclassing, and you want some attributes to be NOT overridden, then please do not use double underscore.

Anyway, if you want to know more about this please watch this great talk about python classes from Raymond Hettinger. The above link will take you exactly to the part where he talks about double underscores but I highly recommend watching the full talk. It explains in details what you need to know about classes in python.

--

You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/b1abb0d9-541e-45cb-acb2-9331073fa91b%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Cedric Bazillou]

Usually as a maya developper I tried to use what comes from the API...

http://help.autodesk.com/view/MAYAUL/2017/ENU/?guid=__cpp_ref_class_m_bounding_box_html

the MBoundingbox class provides 2 useful methods : contains and intersect ( one if for point, second is for a second bounding box)

So here the answer is trivial as a ray can produce a boundingbox and your problem solved in 3 lines... 

what a lot of python programmera forget is that you are doing work inside a dcc and thus you need to take the time to learn/ master this platform before coding thing yourself or try to fight it

[Alok Gandhi]

what a lot of python programmera forget is that you are doing work inside a dcc and thus you need to take the time to learn/ master this platform before coding thing yourself or try to fight it 

I agree absolutely! Code reuse is a must if it exists. From a pipeline development perspective, most of the time you have to write DCC (and also at times Platform) agnostic code. In such cases, you usually end up better writing generic code that works out of the box (and hopefully using native language libs) or a limited use of native API wherever you need it. This way your code runs everywhere and you have better opportunities of writing flexible, customizable and extendable code. It all depends on what the end goal is. But again I do agree that one must have a good grasp of native DCC API's as well. I would use DCC native libs for DCC specific code which covers the application idiosyncrasies (for example when you need to access application features like DAG node attributes and scene graph modification in maya) and for rest of it I would try to write my own using native python libs and features.

--

You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsub...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/a149eb2c-b060-4159-b464-1825a6b41573%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[Cedric Bazillou]

Hi Alok,

i agree with your view as well, and intellectually understand the reasoning on the pipeline  level:

In your case getting the data in and out the DCC with reusable code base maximize your efficiency. 

What saddens me is some of this logic in action (on the tool side) in middle to big places.

Personally i come from an art background and had to build my own tools or devise my own techniques as it was clear what i wanted was too different to hope having it made by someone else.

As a rigger and character TD developing my tool is a  means to reach and produce better content ;those are byproduct of the process and can be trashed at any moment notice without regrets.

For this reason I never understood fabric engine advertising materials on sharing rigs across DCC...

Usually when you choose a commercial software you try to use it for its intrinsic qualities:

let say you will want to use :

• 3dsmax for modeling/ texturing strengths
  
• motionbuilder for performance/preview  and editing of biped creatures
• maya for its animation capabilities ( which cover rigging robustness).

Does it make sense for example to write tools for motionbuilder in order for it to behave like maya or to swap to maya all together.

Or lets assume you are a video game developer and use 3dsmax, across the years your expertise with dotnet grows in parallel with your code base .
At some point you might want to switch to maya:

is it sane to think you can shove those tool in a new DCC with no effort?

Will it not be safer to use the c++ or python layer to interact with maya?(hell even the python 2.0 api layer is buggy and incomplete after all these years ( and dont get me started on pymel)).

Anyway thanks for your point of view!

[Rémi Deletrain]

Thank you for your answers that are very enlightening.

I agree that using the Mayan API is the easiest. I find that the Maya API is extremely well provided and, in addition, relatively clear compared to other ... I have reasons not to use it in this case: - The first is to take a more important step in math and to understand better certain calculation process. In order to improve some of my rig techniques, but also in the development of some tools. - The python is excellent for prototyping, fast to write and no need to compile. I make codes in python that serve me as a lib. Some more complex and gourmant codes are a very very good optimization exercise, because the python is heavy especially in iterations. Once the optimization suits me, I pass it in C ++ if necessary (and if I have the time in the production period) - Another, as you said, is that using an API makes the deportation difficult or impossible in a certain case. - There are still others but I will not do all the lists :)

[Rémi Deletrain]

I do not think that it is useful to reproduce all the behaviors of the software that we love in others.

On the other hand some tools in some software cruelly lack in others and it can be interesting to implement them.

The pymel is really very heavy, it allows to play with the api in a simple way, but on certain code are really too heavy. We pay the price now, I had to transform some pymel code into cmds to win several tens of seconds see sometimes full minutes ...

[Cedric Bazillou]

Good luck with the pymel roll back

Not too long ago it seems mandatory people have to bash mel  in order to promote pymel.... we now have a new generation of maya user which are mel illiterates:

they cant use the expression editor, parse ascii file using maya components or understand user setup or module files. ( what really amuse is to see that if you want to obfuscate your code nowadays you can write it in mel...)

Even on the developer side at Autodesk there seems to be questionable move

The latest version of maya (2017)is the worse for that:  adding callback to close node editor and polluting our plateform each time you open a new file (3 seconds clean up...)  ( why is arnold/pose editor loading pymel which will override all the loaded python plugins ?)

[Rémi Deletrain]

It's not that complicated. It's masked api. Once you know the API it's very simple to convert the pymel. Indeed the number of people who read the mel is more and more reduced. I can translate or write the mel but I do not like to use it so much :)

With the nodal I find the expressions less and less useful, but parse an ascii file is indispensable in maya. The number of times we had big problem and the only solution was to take the file ascii ... I even saw scripts that allowed to render a binary file in ascii. They are not very clean but it saves your life. I did not look too much at the 2017 version yet. The few tests I have done have ended in crash and the long-awaited optimization is far from the expectations of users ...