Are custom channels supported? It’s in the Magmaflow interface, and it lets be set/get them, but they don’t work. I suspect they aren’t supported as there’s no way to know if the modifiers in between will trash that data right?
For Vectors, you can use Mapping channels to a certain extend and sample data using VertexQuery and FaceQuery if necessary in the next Genome above.
We have it on the Wishlist using the PerFace and PerVertex Data interfaces available in Max, but these are not exactly native to the modifier stack and we wanted to start with the usual suspects.
Ok. I wanted to avoid using mapping channels for preset modifiers in case the incoming mesh was using those channels for something else, but I guess that’s something we’ll look out for.
Too bad we can’t expose MappingN where N is an integer. Then the modifier could let you choose which channel to use for things. Imagine if we wanted to make a general UVW->VertColor modifier where you chose the channel and it copied it to the Color.
True, it would be nice. I will add it to the Wishlist for the future.
Instead of exposing the MappingN as Int which would not include TextureCoord and Color (channels 1 and 0), I went ahead and made the InputChannel node exposable in the UI. So now you can expose the actual drop down list with the current Sort/Filter Mode! I also added a new Mapping Only filter mode which gives you “Color”, “TextureCoord” and “Mapping2” to “Mapping99” in the right order. You can check “Expose” in the InputChannel and the end user can select the channel he wants to use as input.
The exposed list will be stored in the sorting order that was active at the time of exposure, and the tooltip will list that mode, e.g. “2: InputChannel: Mapping Only”. You can use this for other variable input channel controls too, but it is most useful for mapping.
This does not solve the problem with exposing the source channels of a FaceQuery or VertexQuery node, will have to see if I could make those exposable, too.
Ooooo… Nice. The exposure/control stuff is important if we want to make these complex without being difficult.
Speaking of, it would be cool if there were Genome controllers. Output a float or position or rotation or whatnot. Would let us make “particles” or fancier rigs or just be able to have a Genome controller affect a parameter inside a Genome modifier.
Speaking of, just different, we can only pull values in from a PropertyQuery, but not assign controllers to anything that isn’t exposed, right? Just checking, as I’m seeing weird stuff in Track View, like “??” and “KCM_CA”.
It is on the Wishlist, I put it there 
Please keep in mind that Genome 1.0 is pretty much feature complete as of tomorrow’s Beta 4 (speaking of the underlying plugin, not the UI).
We are moving to bug fixing only. Please keep on posting wishes, but remember no core changes will be possible from now on.
PropertyQuery is meant to access anything MAXScript can access from the specified InputObject. Things like “pos”, “transform.row3”, “material.diffusemapamount” etc.
The “??” is a bug, no idea when it will be fixed 
“KCM_CA” is the default name of exposed Custom Attributes of Krakatoa, the name will probably stay. The tracks under the KCM_CA are automatically instanced to share controllers with the actual tracks of the Genome modifier. The tracks under the Genome modifier’s subtracks are accessible, too and have sub-tracks with Controllers (only if they represent InputValue nodes). They should be accessible even without a license.
Keep in mind that loading a preset or using the Undo/Redo in the Editor while in license mode will recreate all nodes and replace any custom controllers with default ones. The presets also store animation keys, so saving a flow that has keyframed inputs will bake those into the preset file.
Will ToCamera be in 1.0? Or is that going to be pushed to a later release?
We had lots of problems with it. The plan right now is to remove ToCamera/FromCamera from 1.0.
Instead, we decided to modify the ToSpace/FromSpace to accept an optional second input of type InputObject, so that you can expose it in the Command Panel and let the user pick the reference object. This has the additional benefit of being able to perform PropertyQuery AND ToSpace/FromSpace using a single InputObject node without having to pick a scene object in multiple nodes. Obviously, this means you cannot use Perspective viewports without an explicit camera. 
We might revisit the Camera ops in the future, but right now they are gone as of Beta 4.
Yeah, the current-viewport mode was something we really miss. For Krakatoa, we did a lot of viewport culling and view dependent shading with the KCM’s but lost it with Magmaflow. I’m trying the same tricks out with Genome now and miss it again.
Unless I’m really confused, the code for KCMs seems to indicate that ToView and FromView nodes had nothing to do with the camera’s projection. They just transform points into or out of camera space. So I don’t see anything you’ve lost the ability to do.
}else if( operatorType == "ToView" ){
tm = parser.get_scene_context().get_camera().world_transform_inverse();
}else if( operatorType == "FromView" ){
tm = parser.get_scene_context().get_camera().world_transform();
}In Krakatoa with Magma 2 you can do that exactly with the ToCamera/FromCamera nodes. That was possible because Krakatoa PRT objects aren’t part of the modifier stack, so they get all kinds of interesting information like renderer specific stuff (ie. the camera). Genome is part of the 3ds Max geometry pipeline so it has no way in general to know anything about the camera.
They didn’t require a camera. So they would work in any view, not just a camera or light view.
Not sure what happened with this… viewtopic.php?f=29&t=6667&p=26781, if it was resolved or not.
I can’t recall either. 
I think its correct now, because a Krakatoa ToCamera is the same as a ToSpace with the camera selected.
But is ToCamera different from ToView (from the KCM)
I think they are the same now. I had probably inverted the transform at some point.