Genome Beta Documentation

Ok, you have been really patient, we hope you will find this somewhat useful :wink:

thinkboxsoftware.com/genome-index/

Please note that the examples are work in progress and there are tons of other possible applications that we havenā€™t illustrated yet.

Me like!

The screw modifier example is amazing.

wow, looksreally amazing!

just one thing Bobo,ā€¦ the address of the Genome documentation isnt really very secret.
ā€œhttp://www.thinkboxsoftware.com/genome-index/ā€
You announced the name GENOME alreadyā€¦ so coming to ā€œgenome-indexā€ after everyone know the name is not a big step anymore in my eyes :wink:

Just my two cents :slight_smile:

It was kind of intended. :smiley:
The link was actually discovered 6 hours before I posted it here, and the docs are already indexed by Google.

In fact, if you have Krakatoa MX 2.0.1 or higher and search for ā€œgenomeā€ in its script files, you will find very clear indication of what it is :wink:
Krakatoa and Genome have been sharing the Magma editor code since December, just nobody noticed.

The Magma editor in the upcoming Genome Beta is a step ahead now and will serve as base for KMX 3 - we rewrote some aspects of the internal MAXScript exposure to make it easier for us and everybody else to work with, while preserving compatibility with the KMX2 file format. We will keep on using the same code for the editor, but Genome and Krakatoa will ship with their own copies so you can have the one without the other, or even two incompatible versions of the Genome and Krakatoa MagmaFlow scripts working at the same time.

We have a first build of the installer and we are testing it. So we are on track for next weekā€™s Beta begin.

Hahaha, ok thatĀ“s cool. I like this approach I must say :slight_smile: Was just wonderingā€¦
Take care,
Markus

New tutorial added to the Genome documentation:
Conform To Surface Modifier

This is Part 1 of the Conform tutorial and still WIP. More to comeā€¦

Good stuff! Iā€™ve been meaning to learn the magma editor better but now I will have two very good reasons to learn it.

So do you see this being used for anything else than a super advanced volume select? I obviously see the massive advantages of Genome over volume select and what you canā€™t achieve with volume select (like particles etc.). I havenā€™t had much of a chance to think about this but what are some of the practical scenarios that you see this being used? I can see the obvious once like any type of imprint into a surface (a metal door bulging by the force of something strong, foot prints in mud/snow). Iā€™m not sure Iā€™ll be modeling screws with this tool (seems a bit overkill :stuck_out_tongue: ). Would be great to hear some grand examples of the type of effects you envision this plugin being used for.

Back at Frantic, you might remember a bunch of in-house modifiers like ā€œCopy Vertex Color To Selectionā€ or ā€œCopy Selection To Vertex Colorā€. More recently we had a ā€œCopy Mapping Channelā€ modifier for dynamical transferring of coordinates between objects, another modifier to select elements by area,volume or vertex/face count and delete them to clean up detached droplets from Frost and a bunch of others. When we started thinking about Genome - then called GCM - years ago (first prototype was probably around 2008 or so), we wanted to have one modifier that can do anything a TD might need without bugging the RnD department and waiting for 3 days for somebody to write it in the SDK. In fact, most of the examples you see in the documentation were developed in less than 15 minutes.

I admit that the expansion of the Vol.Select modifier has always been a major goal. Volume Select is the ONLY procedural selection modifier in Max and can do amazing stuff, but at the same time it is the biggest pile of steaming poo when it comes to its code. We could never make it fully operate on PRT objects in mesh selection mode as it would crash Max, and in the one build where we managed to make it work, it screwed the transforms of the gizmo. Also, we wanted something a bit faster. Admittedly, in the first Beta of Genome we wonā€™t be that much faster, but by the end of the Beta Genome should really kick its behind when it comes to mesh-based selections (we have some refactoring planned to get there). Right now Genome is 38% faster when selecting by a procedural texture map. I benchmarked mesh selection yesterday and with relatively heavy meshes (100K vertices, 100K faces), Genome is about 2 times faster. We want it to be ORDERS of magnitude faster, like in todayā€™s example of surface conforming where it is about 500 times faster.

But as you read the docs, you will see that in addition to selecting and deforming, Genome can be used to generate UV coordinates, perform data transfer within the same mesh and between meshes, perform data acquisition from particles (we have the other direction covered with KCMs already), and there might be even more things it could do we havenā€™t covered in the docs or even discovered yet (thatā€™s what the Beta is for). Also, Frost and XMesh could expose more data for Genome to deal with in the future.

You should also not underestimate the power of custom deformation modifiers, esp. layered ones. The base code of the Bulge/Screw modifier has produced some amazing things for me esp. when applied to non-cylindrical objects. And the ability to tweak the actual code of the modifier while designing the effect is what all similar toolsets in other apps like Houdini and Softimage are after. It is quite a glorious creative experience. Even just adding a Curve control to a Skew modifier produces something that is difficult to achieve in Max out of the box.

I would like to see how people model a screw, but I would imagine many cases where using a deformation modifier would be a fast solution, since the flow ships as an example and it is real time and non-destructive. But even if it turns out we just cater to the motion graphics market (which Autodesk is aiming at lately), it would probably be rewarding enough.

We are trying to keep the scope of Genome 1.0 relatively narrow, but aim for speed, flexibility and accessibility. We have specifically scheduled things like History-Dependent channels and evaluating data at a different time than the current for future versions (the latter can be achieved using XMesh though). Same applies to topology changes, mesh cloning, edge editing, spline support and many other areas.

I feel that if you can create even just 100 different modifiers with Genome, it would be more than what Max ships with already, so it should be worth it. Especially if they do exactly what you need in every particular case instead of something close but not quiteā€¦

Thanks for the reply Bobo and you bring up some great points. Iā€™m positive it will be an invaluable tool and to me, even having Genome act as a super fast, expanded and powerful version of Volume Select is a huge step forward. Going to dig into Genome when the beta is released and try to brain storm. Maybe in conjunction with Naiad and PRTs I can do Realwave type stuff instead of having to generate a frost surface as one example.

Looking forward to it!

Out of curiosity, would the ability to output new vertex IDā€™s be within Genomes scope for 1.0? There are many times where this would be super useful. Some mesh IO methods end up reordering them and some tools such as Morphs or TP use that data. It would be cool to be able to change it.

In the current phase, topology changes are NOT on the list of things we plan to support. The Genome modifier DEPENDS on the order of the vertices/faces to perform its iterations, just like the Magma modifier in Krakatoa. So index reordering will not be possible for now.

We are not excluding the possibility for this to be allowed in future versions. I will log this as a Wish.