Object->Geometry

Deprecated Genome Bug Reports
1

When you plug an object node into something that wants geometry (like rayIntersect) the magma listener reads:

NOT Current Modifier: Magma internal error at line 521 of file "C:\Users\Darcy\Development\MagmaProject\frantic/magma/simple_compiler/base_compiler_impl.hpp"()

instead of something more helpful like “Unexepcted input…expected geometry got Object”

This also happens in Krakatoa Magma.

2

We are in the process of adding dedicated C++ filter functions to determine whether an object is a valid class for the various inputs. For example, a PRT Loader object is of Geometry class, but is not a valid source for InputGeometry (but it is for InputParticles). So far, the filtering in Magma was done via explicit class name lists hard-coded in MAXScript. The Magma core expects that the UI will prevent you from picking an invalid object. It looks like the existing UI code did not succeed in that. Hopefully the next version (coming soon in Krakatoa MX 2.3) will do that.

Out of curiosity, what kind of Object did you plug in?

3

I believe it was a primitive, like geosphere or capsule.

4

That should not fail as InputGeometry nor as an InputObject. Can you send me a scene that shows the error?

5

Here you are.
Genome_Obj2Geo_bug_2014.max (208 KB)

6

Ok, I see.

We really need a better error message for this case.

Obviously, InputObject is not a valid input to IntersectRay, only InputGeometry is.
Which means you would have to pick the object twice, once as a geometry source and once as an object source.

Thanks for the report, will log it.

7

This annoys me a lot.

Makes it very messy to package up operators.

I understand why you have to do it that way, I just wish there was something that could make it nicer for other users.

R

8

I totally agree with this sentiment. :slight_smile:

The same applies to the opposite direction - accessing node info from an InputGeometry node, e.g. TM etc.
Unfortunately, InputGeometry and InputObject are a bit different at the moment - the one supports multiple nodes, the other just one. I guess a conversion node that takes InputObject and extracts the Geometry if available to produce a single TriMesh value equivalent to a single object picked in InputGeometry would be the way to go here.

I am going to escalate this internally and see what will happen…