1 Comment

modo meets Cinema

Ever since I wrote that little article on modo‘s vs.  Cinema 4D‘s renderer this has been an extremely popular topic and people seem to hunger for more. Therefore I’ve sat down and collected my thoughts. I have used both programs for a long time – modo ever since version 1.0 covering about 8 years and Cinema 4D on and off since release 5.21 about 15 years ago. Interspersed with this has been a long use of Lightwave for almost 10 years and 5 years of also using Maya. Throw into this mix many auxiliary tools and programs plus my usual keen interest to try out demo versions/ trial versions and you may get an idea and understand some of my views.

It is equally important to understand what kind of work I do. A lot of my 3D work covers technical, process and scientific visualization. There’s of course also some motiongraphics stuff like logos or swirling background patterns. And then there’s of course my geeky concoctions like exploring algorithmic structures and patterns for instance for plants, toying with particles or building stock setups that might come in handy in the crunch. I don’t do any character work, so if you are looking for advise on rigging, lip-syncing and all that you need to look elsewhere. Instead I will focus on things like modeling, animation, rendering and so on.

One last thing you need to consider is that I don’t care much for trimmed down versions of any program. Maxon may sit in their offices all day and think about how they can sell one more license by creating more Lite, Essential, Broadcast or whatever fancy versions, but to me it’s always the full deal – Studio. The thing is you never know when you might need a specific tool or feature and unless you actually have it at hand, you may not be aware of its value and how it may help you solve problems and enhance your workflows. People use the Hair module to create dangling wires all the time and in my engineering visualizations I use MoGraph Cloners extensively to create arrays of identical sub-assemblies or distribute nuts and bolts, so for all intents and purposes this module not being part of the Visualize package makes absolutely no sense to me. Of course this doesn’t mean that those reduced editions can’t be good enough for you, especially when you are on a limited budget.

For this comparison Cinema 4D R15 and modo 701 SP 3 were used as reference, but some of what is written here naturally will also apply to other versions of these programs.

General Differences

Before delving into the details, lets take a more general look at the two programs with regards to their underlying paradigms and philosophies and how it will affect your workflow. Let’s start with modo.

Very much like Maya, modo is built on top of a command-centric engine. This means that each operation triggers some internal command. Those commands show up in a command history and can be accessed with the SDK. By modifying parameters within the command strings you can set different tool options or get different results from operations. This goes as far as being able to create icons/ buttons or keyboard shortcuts for different settings for the same tool. This will allow quick work once you have spent a little bit of time creating your own customizations. One further advantage of this fire & forget approach is that it allows the program to be relatively lightweight – you often can store only the command itself e.g for an undo instead of the result and the data an operation produces. As a downside this adds a certain intransparency and overhead. Data that has been generated by a command is not directly editable and will require yet another command to modify it. An extreme example for this is setting constraints or rest positions. When you edit a complex hierarchy e.g. for inverse kinematics you may end up assigning and un-assigning motion targets over and over while you tweak them. In a worst case scenario you may even end up rebuilding the setup from scratch because it is easier than fixing a botched one.

Cinema 4D is an entirely different beast. Its system is two-fold. Many modeling tools use a conventional edit and undo system. This part is not accessible by the user in any way and you have to live with the tools as they are provided and set their options as needed every time. This is one of the reasons why modeling can be quite a chore, but more on this later. The other part is the parametric part with all the dynamic primitives, generators, deformers, tags and all that. This allows you to keep things dynamic and editable and since many of these parameters are animatable as well you can create some quite interesting setups. On the other hand there is one big disadvantage: The more complex your scene becomes, the slower things can get. Traversing hierarchies and calculating all those parameters simply takes time. This can in particular become problematic while you work, but also has repercussions for animation and rendering. If you’re not careful you can run into all sorts of problems an inconsistencies such as objects that are supposed to follow others lagging 1 frame behind or their position being off.

Cinema 4D

Pro

Con

  • parametric items can be edited and adjusted as needed
  • many parameters can be animated
  • hierarchy order determines results of operations = good visual feedback
  • relationships between items can easily be changed
  • no command automation
  • repeating tasks require manual script programming
  • limited undo due to storing more data
  • limited customization options
  • full scene graph evaluation costs performance
  • odd and unpredictable glitches and behaviors
  • hierarchy-dependent evaluation can require structural changes to scenes

modo

Pro

Con

  • automatic command history
  • (theoretically) unlimited undo
  • customizable shortcuts, tool presets and UI elements based on command strings
  • re-use command chains to repeat complex operations
  • no parametric objects to speak of
  • parameter animation only on special items/ channels
  • repetitive extra commands to change item relations

Performance and Stability

There is an persisting urban myth that Cinema 4D would be kinda unbreakable and never crash while at the same time modo would crash all the time. As you may have guessed, this legend is most prominently purported by users who mutually have not used the other program. So what is true and what is not?

Cinema‘s alleged immunity to crashes can mostly be attributed to its underlying processing model that often prevents hard crashes that kill the whole program. The program uses extensive threading to isolate different operations and process them in parallel. The interface has its own thread as do deformers, generators, the material editor and so on, so if one of those crashes or freezes, the attribute editor for a function or a panel may not respond, but you would e.g. still be able to save your work or even navigate around the viewport. Many times simply closing a panel and re-opening it would even bring things back to normal. So in a technical sense the program can still crash a lot, you as a user may just be lucky to not lose all your work. The one big downside with this approach is that you could end up introducing bad data – if you caused the problem by using excessive or wrong values, there’s a good chance those values will stick when the program has recovered and you could end up in a cycle of death where even touching a control causes the same mishap. Also the concurrent processing can contribute to the delay issues mentioned in the previous chapter.

modo uses a more conventional approach. This is in part owed to its command-centric architecture which requires things to happen in a specific order and as a result you may spend time waiting for the program to finish an operation before the next. This also has the downside that indeed if a single specific operation fails, it can drag down the entire program. However, over the years with each version the number of bugs and issues causing crashes has diminished considerably so unless you do something extremely stupid like creating a gigazillion instances of an item and thus exhausting all your system memory or using an invalid command string, it is actually pretty difficult to make the program conk out. At the same time this doesn’t mean that the program doesn’t know anything about threading. Dealing with instances and replicators, rendering operations, the preview window and other things are of course split to maximize efficiency. However, this threading happens in the context of the current tool or feature set, not globally.

Display Performance

Yes, we all live in a day and age where we all would like to swivel around in our viewports as fast as possible and not wait for a simple sphere to draw with several seconds delay like when I started doing 3D in the early 1990s. Additionally, we would like our viewport in shaded views to be as representative of the final result as possible. So how do the programs fare in this department?

There is no clear winner here. The problem is that to me modo feels “snappier” all the way and more intuitive, but does not bother much with displaying certain dynamic shading effects for procedural textures, shadows and so on. It relies on the render Preview for this (more in the Rendering section). It also has an added advantage because unlike Cinema 4D it does not need to evaluate dynamic objects and everything already exists as polygon data ready to be used by the graphics hardware. Also modo behaves much better with big scenes that have thousands of instances – that is if you can get over the program sometimes taking quite a while before actually having loaded the geometry. The chosen drawing type does not really matter since the program will be similarly responsive whether it’s wireframe or shaded modes. There is, however, a definite impact on display performance with deformation/ transform operations at the element level such as moving points on a complex mesh.

In contrast to this, there almost always is notable delay in Cinema even with some simple scenes because e.g. spline-based objects need to be converted to polygon data first before rendering it with OpenGL. In addition it tries to simulate many render features already in the viewport which cost additional resources. That may sound like it is superior in that department, but in my view the opposite is just true – it needs to do this because to date it does not have a decent interactive render preview. As opposed to modo the display type chosen definitely matters and sometimes in a rather peculiar way. A good example is working on my CAD scenes where there are literally as many lines as there are polygons. As a result, the more you are zoomed out and more lines need to be drawn, the slower things get. This gets even worse if you mix different drawing modes using display tags or you switch between different views with different modes.

On balance they both have their quirks and failures. Personally I prefer modo‘s approach – I like to keep things simple while I work and can go without the fancies as long as I get a maximum of performance. That doesn’t mean that the program couldn’t do with a viewport type that supports all textures and shaders ‘cos after all it might help to make it more attractive for realtime content developers like game artists, but for now it’s a low priority on my end. For Cinema, Maxon will simply have to figure out how to implement a sensible caching system do avoid all those drawing issues.

Cinema 4D

Pro

Con

  • viewport simulates a variety of shaders from the material system
  • considerable delays with scenes containing lots of parametric objects
  • sometimes massive delays when switching views with different display types
  • performance gets worse with many elements to be drawn

modo

Pro

Con

  • fast interaction even with large and complex scenes
  • chosen display type has little influence on overall performance
  • no delays when switching viewports
  • no advanced shading from the material system
  • notable performance reduction when operating at the element level (points, edges, polygons) on reasonably complex meshes

Interface and customization

Both programs have a reasonably clean interface that is pleasing to look at and feels professional using graphical icons on a dark grey background. At the same time both share similar failures. The icon design is somewhat inconsistent. In particular modo suffers from icons being way too colorful and each of the sub-sets having a different design philosophy. You can literally see how icons were created by different artists as new features were added with each version. To my own shame I’m guilty as charged since I contributed to this mess. I really need to sit down and come up with some good ideas and create a better set. Cinema 4D is a bit better but suffers from some icons having been revised with every new version, so things are becoming a bit confusing. In addition there is a somewhat ill-conceived attempt at color coding, which just doesn’t work. The crux with any such system is that you never have enough colors that a) can easily be distinguished to provide visual guidance and b) assign a color to each object type or function category. You simply will run out of colors long before you have come up with any resonable coloring scheme.

In terms of customizing the interface layout both programs offer the same basics like rearranging panes, creating tabbed layouts and placing icons. However, once you need to go further, things quickly skew in favor of modo. You can easily create completely new panels that collect your most used functions in the same place using the Form Editor, including full access to all standard interface controls. The downside here being that many of those panels are hidden in pop-ups, pop-overs and context menus, sometimes making it difficult to actually find them in the program when you don’t use a specific feature they are tied to. Without getting into Python or the API this kind of flexibility is not possible in the same way in Cinema. The only place where you can create custom interfaces is when you use User Data or create a new icon toolbar. Generally I also feel that Cinema 4D does not use a consistent methodology when and where to use what kind of control. Sometimes you will find arrays of checkboxes on one tool and then a pop-up to set similar options on another. An example for this would be settings for initial axes when you create an item.

There are also times when one will need multiple panels of the same type. Especially for animation you will often want to pin down or lock specific property/attribute editors, use multiple filtered scene trees and work in different graph editors on different animation curves. This is an area where modo‘s versatile and flexible form system beats Cinema every time. You can quite literally have an infinite number of the same panels and customize them as you need and whether it’s a toolbar, a viewport or a curve editor doesn’t make a difference. You could even go so far as to create instances of some default panels as separate forms and permanently derive customized versions. The only limitation is that you may run out of screen space and naturally your graphics hardware may not be able to keep up when you have to many viewports or other hardware-accelerated panels. Cinema 4D does not have full panel instancing at all, but in recent versions at least provides the opportunity to use multiple attribute editors and up to 4 Object Managers and Timeline windows.

Finally a few words on keyboard customization. This is again an area where modo clearly wins. You can quit literally assign shortcuts to everything until you simply run out. You can also define where a shortcut is supposed to take effect. Cinema does not nearly offer the same amount of control. While you can change a lot of key assignments, some default key mappings will never be available to be changed by the user. Because of this you can also inadvertently create assignments that result in odd behaviors because two unrelated functions respond to the same keystrokes.

Cinema 4D

Pro

Con

  • reasonable default layouts and shortcuts
  • no custom panels from scratch
  • only basic panels to store pre-existing icons/ buttons
  • sometimes conflicting keyboard shortcuts
  • not all options can be customized

modo

Pro

Con

  • flexible creation of new panels without additional programming
  • user can include his own scripts, commands and icons without additional work
  • multiple ways to display the same panel, allowing to choose the best method for a given situation
  • some layouts are too complex and overloaded
  • many hidden options that require modifier keys like Alt and Shift
  • many panels (forms) only accessible via right-click in not so obvious places
  • inexperienced users can be overwhelmed by too many customization options and actually destroy even the factory default layouts

Modeling

I started using modo as a replacement for Lightwave‘s Modeler when things there seemed to go down the drain. Undeniably this has ever since influenced my view of it. However, I dare say that when it comes to polygonal modeling, you’ll be hard put to find anything better. Of particular note here are the Action Center and Falloff options plus things like Background Constraints and the Workplane. All of these allow you to modulate the influence of your tools and align operations with your preferred axes. Another thing that contributes to this flexibility is the pretty good selection system in combination with the quick viewport navigation that allow you to pick the right elements. Ever since symmetry modeling got some major love in version 601 even that actually is fun to use.

Unfortunately, and this is where things get a bit dicy, while the polygonal and subdivision modeling tools are excellent, there is not much else there. Splines only exist as auxiliary items for extrusions or as guides and while there is an infrastructure for it, procedural geometry items are limited to what I would call tech demos for creating gears and some fractal structures. Some operations like Booleans also have a tendency to take quite a long time and produce some not so great results. And finally, modo still needs to work out its snapping logic, which most of the time is practically unusable.

Cinema 4D takes a broader approach and can benefit from its procedural approach in some areas. Up to a certain point you are not committed because you edit a parametric generator object like e.g. an extruded text and not a mesh. If you know your way around, you can create some pretty elaborate stuff this way. The many spline tools will also help you considerably with graphical work for logos and other stuff that may have originated in a vector drawing or CAD program. The splines suffer from some issues with tangent continuity and shapes sometimes not being possible to close no matter what, but with a little work  like inserting some extra points this can usually be fixed.

In many cases there will however come the point where you need to Convert to Editable Object, meaning a polygonal representation for refinement and then things may not look quite so good. One of the problems you will encounter is that for many objects the program produces discontinuous geometry where for example the caps of an extrude object have a different topology than the sides and are not actually connected. Fixing these issues to get watertight meshes for simulations, boolean operations or just texturing can be time-consuming. This is further complicated by the polygonal selection tools not being as smart. Sometimes you end up selecting not enough, other times too much, yet another time nothing gets selected and the pre-selection highlighting just flickers like crazy and you never know what you did wrong.This is more a feeling than something I can actually put in words, but it just doesn’t feel as streamlined.

As someone who enjoyed n-sided polygons in Lightwave long before Cinema ever knew this trick it also irks me massively that it just doesn’t want to retain the n-gons. Many operations arbitrarily triangulate the mesh or parts of it, which then may interfere with follow-up operations like edge bevels or putting your mesh into a subdivision object. You often spend extra time collapsing multiple triangles back into a single polygon area, merging and removing extranuous points and then doing your next operation. One thing that is also inconsistent is the difference between some tools being commands vs. others being interactive tools. This still confuses the hell out of me at times, especially since some tools respond and are constrained to selections, others ignore them completely. There is also a certain redundancy in some tools like the inner extrude and normal extrude, which contributes further to this feeling. One thing that definitely works better is the snapping.

Cinema 4D

Pro

Con

  • parametric object and modifier types
  • comprehensive spline tool set
  • animatable modeling operations like extrudes or booleans
  • acceptable polygonal tools
  • reasonably working snapping
  • parametric objects produce “bad” geometry once converted
  • program does not deal well with n-gons and arbitrarily triangulates them
  • subdivision modeling requires specific object type and is impaired by aforementioned issues
  • selection tools, including pre-selection highlighting, tend to be a bit wonky
  • some tools are redundant
  • limited options for soft selections/ falloffs and alternate transform axes
  • workplane and viewport alignment are lacking

modo

Pro

Con

  • refined polygonal modeling tools
  • native subdivision modeling supporting different types
  • falloff and action center system to limit operations
  • workplane and viewport alignment allow exact placement of items and elements
  • no parametric geometry types worth mentioning
  • splines serve only as helper constructs for extrusion paths, text, deformers, replicators and so on
  • slow mesh edit operations like booleans
  • snapping is mostly useless

Texturing, Sculpting and Painting

Of course when talking about modeling, we can’t leave out sculpting and (UV-)texturing. Sculpting has existed since version 301 in modo, but has only recently been introduced in Cinema 4D. As mentioned in the introductory chapter I don’t do character stuff, so my use for such tools is limited, but from my doodling around and occassionally “sculpting” piles of garbage or landscapes, they both seem to be similar in performance. However, naturally they are not specialized like Mudbox and ZBrush (nor were they meant to be)  and need to work in the context of a generalized 3D program, so there will be limitations.

An entirely different story is UV layout work for texturing. Once upon a time Cinema 4D took easily the crown with its texture painting and UV editing tools in Bodypaint, but ironically now has hopelessly fallen behind because nobody took care to keep the toolset current. Most artists these days prefer to do this work in other programs and then import the result. This unfortunately also affects procedural object types such as spline extrudes which generate implicit UVs. Converting them pretty much gives the same issues for the UV set as it does for the actual geometry. This also includes textures using the parametric mapping types like planar or cubic once they are made sticky as an UV set.

Luxology on the other hand have kept working on the texturing tools in every version and thus they are much more rounded out. Being based on “normal” polygonal tools, but operating in UV space they can be easily learned and used even if like me you only occasionally use them (as for technical visualization plain materials and procedural textures will often suffice). This also extends to workflows like retopology to rebuild a sculpted mesh as a clean mesh for animation, working with vertex maps and the preparatory work needed for baking textures.

Painting textures is possible in both programs, but given the already mentioned legacy issues is not as intuitive in Cinema 4D. Laying out the UVs simply takes too long to get there and then even being able to work on layered PSDs isn’t a saving grace. Being dependent on the Raybrush and test renderings to preview textures on multiple material properties also slows down the workflow. modo does the opposite. It much more emphasizes working quickly and getting a reasonably accurate preview with OpenGL and using the Preview renderer. As a downside, textures may need to be separate in multiple material channels and thus need more additional work in an image editing or compositing program to combine and refine them. Still, it simply is much more fun than in Cinema.

Cinema 4D

Pro

Con

  • sculpting works reasonably well
  • implicit UVs on parametric object types
  • parametric mapping types
  • UV layout work is painful
  • texture painting not interactive

modo

Pro

Con

  • reasonably good sculpting
  • automatic UV generation on primitives
  • UV and topology tools based on standard tools and behaviors
  • good automatic UV unwrapping
  • intuitive and interactive paint system
  • easy and accurate preview of multi-texturing
  • more texture files to work with
  • usually more work with external texture editing for refinements

Animation

Making things move can be quite complicated and not only involves creating the actual motion, but also involves additional processes like rigging, touches upon rendering and scene layout, may require simulation stuff and naturally builds on things mentioned before like good viewport performance and an accurate presentation of your scene. It even extends to seemingly trivial things like how well you are able to distinguish items in your scene tree or can manage visibility or their wireframe color. So by all means this is probably the most complex topic of them all and we only can cover the most critical differences.

The obvious place to start is by stating that I do only a limited amount of animation in modo at all. This has in part to do with some of the things mentioned in the General chapter. It makes a huge difference whether you animate an extrusion along a spline based on parameters or if you need to define two morph targets for the start and end of the extrusion, animate the morph blend value and possible need an extra deformer to conform it to the spline. Not only is it simply more steps, but it is more prone to issues like your extrude getting all wrinkled up when using a deformer. Similarly, the overhead introduced by using specific commands to determine relations or set values can become quite cumbersome while you prepare your scene for the actual animation.

The other part that puts me off is the slightly over-organized, highly atomized nature of modo‘s animation tools and associated editors. There is just so many places to go to do some simple things. One of those things I find quite annoying is dealing with deformers for example. They are split across the actual deformation matrix (the deformer item) and the influence item and then you can further modify them with additional falloffs, limit them by weightmaps and mix it all until you are trigger happy in the deformation editor. Things like the spline deformer will even add locators for its points and create its own group.

Now here’s the thing: I understand the advantages like decoupling the actual deformation from the parent mesh item, defining in which order the deformations are applied as well as avoiding unfavorable deformations by being able to explicitly define weight values and normalize them, but the whole system is way too complicated for applying a handful of bend deformers to do a page turn or wrap an object along a spline to create e.g. a snakey animation. This kind of very technical thinking extends further to channel sets, actors, poses, keyframe sets etc., all of which are great means of creating animation that can be put in assets, snippets and libraries to be re-used and swapped out as well as allowing the artist to focus on only the parts he’s responsible for, but in my world there is just never really time to use this stuff and benefit from these secondary organizational structures.

Which takes us to Cinema 4D. While it may not offer the level of refined control modo has it has one big advantage: It is much more visual. Yes, doing everything in the Object Manager is probably the biggest plus here. Instead of using a separate editor, you simply stack your deformers as needed and balance out their values, instead of creating tons of extra Nulls you simply reference a spline in a link field and instead of having yet more editors for poses, weightmaps, constraints and what have you you simply store that info in a special parent object or a tag right next to your objects. This is just bliss for simple-minded guys like me and yes, in the crunch it helps to keep things organized and understandable, too.

Does it have any disadvantages? Yes, of course. The simplicity in setting it up often comes at the price of requiring workarounds to actually make it work, meaning you often end up shuffling around items in the hierarchy, add additional groups/ Null objects or do crazy things like animating stuff in a “neutral” position and then funneling it to the actual place where it is needed using an Instance object. However, it still stays visual and once things have clicked with you and you know how to avoid twitching constraints or flipping Spline Wrap deformers it’s not that much trouble in most cases.

Moving away from these specific (but important) differences, the general toolset for animation is pretty similar. Both programs support animation of all basic transform operations, can animate single property/ attribute channels where possible, have constraints and Inverse Kinematics, deformers and morph tools are available and you can use audio for lip-sync animation and image sequences for backplates and animated textures. Cinema 4D takes this one notch further with its parametric objects which also can be used creatively for animation. A classic example of this would be an animated Boolean operation to reveal internal detail in a closed machine housing or drill holes (though it’s not necessarily the best technique for this due to potential geometry issues causing flickery animations).

Bringing it all together are of course the timelines/ graph editors/ dopesheets/ animation mixers. While they work reasonably okay, neither of the two programs really nails that part 100%. Personally I tend to think that Maya‘s editor back then when I used it was quite good and behaved the way I would want to. For the most part the editors in modo and Cinema suffer from issues in terms of a) fitting curves and keyframes in the viewport, b) tracking what’s actually selected in the editor and c) using sensible ranges to display hugely different value ranges of multiple curves, including resulting velocity curves. For my taste, one has to zoom and pan far too often to center the view to adjust a specific curve or move around a couple of keyframes. Not the end of the world, but you should learn to make friends with some keyboard shortcuts to automatically center your stuff or zoom in on the selection when needed.

Cinema 4D

Pro

Con

  • simple and intuitive handling of item selection
  • visual setup of deformers, poses etc. using specific item types and tags
  • animatable parametric modeling operations
  • complex setups may require extra hierarchies and objects
  • complicated animation mixing/ layering and retiming
  • hierarchy display options in the Timeline window can be confusing
  • unnecessary navigation in the Timeline in graph mode since view does not adapt to curve ranges

modo

Pro

Con

  • full quality preview for animation using the render Preview
  • image sequence painting
  • refined deformation and weighting control based on modeling tools
  • extremely convoluted setup options for deformers
  • bad visual feedback for constraints
  • lack of parameter animation for modeling and other operations requires extra setups and workarounds
  • extra navigation in the curve editor due to unfavorable value ranges
  • adjusting keyframe tangents can be unintuitive

Simulation

Talking about simulation is going to be a delicate topic, mostly because modo has only had these features for a much shorter time and thus they are even far less complete than in Cinema 4D. Therefore this will mostly come down to a listing of the most common problems in both programs. So let’s begin.

In Cinema 4D obviously many of the simulation tools are old as in really old. Thinking Particles made its first appearance in version 8, reflecting the then current version 1.1 of the plug-in of same name for 3D Studio MAX. Ever since there haven’t been many notable changes and enhancements and when you consider, that Cebas now are at version 5 and how powerful this toolset has become, you begin to feel the pain. Similarly, Clothilde, the basic particle system and the Hair module’s guide/ spline dynamics come from the past. Only the rigid body/ softbody dynamics based on the Bullet physics engine are recent. But stay with me for a moment. While this may look grim, the tools are actually still usable and on their own actually aren’t that bad for simple everyday tasks. The real issues are other things.

First, the tools get slow very quickly. Yes, exceeding a certain number of particles can make Thinking Particles appear like it is frozen and this count is unfortunately only a few thousand, not millions. So forget about that ultra-realistic fire simulation. Similar is true for the other tools – using detailed models or complex interactions with lots of collisions renders them practically unusable. Aside from the tools not being multi-threaded this can simply be attributed to their old and not so optimized algorithms.

Second on the list is precision. Even if you use the finest possible settings and let your simulations do the number-crunching overnight, you will still many times see intersections of dynamic bodies or particles shooting through “walls”. This is in part since most simulation types do not use sub-frame sampling, in part simply the math used in the algorithms being too simplistic to deal with certain scenarios.

The third, and that’s one of the two remaining big stinkers, is that nothing goes together with the other. If at all, interaction between different simulation types can usually only be achieved by side-using specific tags and objects and often involves XPresso e.g. to convert some cloth simulation to points in order to pin an emitter to it. Each simulation type uses its own collision methods and associated tags also, which makes things like having a simulated rigid body deform hair or cloth almost impossible.

Finally, and that’s the real kicker, none of the aforementioned limitations would actually be that bad if there was a decent caching system, but you guessed it, it isn’t there. If it was, you could build your secondary simulations based on the cached data of the primary ones and then layer by layer create real complex stuff. You could then even apply deformers or use modeling tools to mangle and refine the data and you could use time-remapping to control the simulation timing. The good news is that this workflow is beginning to fall into place using Alembic, the bad news is that since it operates based on files you need to write them out to disk first and if something changes, you end up doing it over and over again. It’s not a dynamic system.

So in light of the above, does modo fare any better? Yes and no. As mentioned, its tools are perhaps one third or quarter of what Cinema has to show. The particle system is somewhere halfway between being a simplistic basic particle system, but since it already supports things like per-particle expressions (=rules) and custom data channels and can be wired in the Schematic View, it also is somewhat like Thinking Particles already. The performance is also notably better while previewing and, this is where it gets interesting, particles can interact with body simulations as well. This is achieved using the custom data and a handful of items like the Particle Operator. There is also support for basic fluid simulation and flocking, things you would only get in Cinema 4D with plug-ins like X-Particles. The rigid and soft body simulation is based on Bullet just like in Cinema and as you would expect and offers the same feature set. What sets it apart from the other program is that there is actually a built-in global caching system for all of this which really helps once things get complex. Of course Alembic is also supported. This sounds all great, doesn’t it? But hey, not so fast. As you may already suspect from reading the previous paragraphs, it is all very technical and will take you a good time to master even some basics. This is even more so, since the documentation only covers the basics and there aren’t that many tutorials that cover this topic.

Cinema 4D

Pro

Con

  • multiple different simulation systems cover a wide range of tasks
  • reasonably simple to set up
  • performance degrades quickly, so complex simulations are a pain
  • different simulation types cannot easily interact and require lots of workarounds
  • no unified caching system

modo

Pro

Con

  • complex particle tools, including a basic fluid simulation
  • soft and rigid body dynamics that can interact with particles
  • reasonable performance even with complex situations
  • unified cache system
  • difficult to learn and very technical
  • select simulation types not available an system still a work in progress

Rendering

Talking about renderers on forums is a recurring subject and in one such thread another user noted that there is no point in comparing renderers because each uses different algorithms, processing models and optimisations. That’s of course complete nonsense (or BS if you like) because otherwise people wouldn’t go looking for alternate renderers and just happily use whatever comes with their 3D program. There really is no need to make any song and dance about it as there are some simple criteria that define a “good” renderer and can be gauged by any user.

  • It offers good render quality.
  • It supports as many features as possible.
  • It is well-integrated in the program.
  • It is reasonably fast.
  • The settings and options are easy to understand.

That’s all that matters to the user. Anything else is just irrelevant academic blahblah because in the end we all only want to get some pretty pictures. Whether a renderer uses biased or unbiased, which global illumination method it uses, which antialiasing types it supports, if it uses CUDA or not or if it can brew coffee is by all means inconsequential to the artist.

As you already know from my initial article, there’s a considerable difference between the two programs even with what should be the most simple scene – an open setup with just some floor and a generic background, with the only real challenges being reflections, shadows and ambient occlusion. As the result turned out, Cinema 4D completely bombed for the simple reason that the area lights I used in combination with blurry reflections so massively increased render times. Similar behavior can be observed with using transparencies in a scene. You can wait literally forever to render a machine made of “glass” as I occasionally do to show interior detail. The performance just isn’t there and while with extensive tweaking and experimentation you can find render settings that shave off a few seconds or minutes here and there, I have yet to succeed in matching modo‘s lightning fast renderer. It also barely makes a difference whether you use the Physical renderer or the standard renderer in scenarios like mine. It might if you do architectural work or similar, however, and can benefit from some of the new global illumination optimizations.

Other render features simply suffer from being old. This imposes quite a few performance issues, but also several limitations. Hair for instance will suffer from flickering shadows, not show up in reflections (unless converted to polygonal hair) and not interact with other volumetric effects for that same reason. On that note, while the program has reasonable volumetric lights, you can pretty much forget Pyrocluster for smoke and similar. You will almost certainly end up buying plug-ins for that. The one thing that stands out is still Sketch & Toon which despite its performance issues is probably still the most comprehensive NPR (non-photorealistic renderer)/ cartoon renderer.

Tying in with the renderer is of course and material system. Here Cinema knows a few cool tricks like the Proximal shader that can be exploited creatively, but otherwise this stuff looks a bit dated. Without a lot of fine tuning all materials can quickly end up looking the same and critical shader controls like the Diffuse amount are not enabled by default, increasing the risk of blown out highlights or flat colors. There are no controls to create physically accurate materials or at least link and limit shading values, so a lot of experience and testing is required. This also somewhat limits the ability to re-use presets, as there is always the chance that merely using a different lighting setup may require changes and that can get annoying. Even more so, since there is no referencing/ instancing of texture and material channels and you have to go into each slot again and again. Plug-ins like the free cmNodes or Blackstar‘s Reference Shader can help but are at best workarounds. Eventually Maxon will have to resolve this in the proper way by adding a native functionality.

The biggest workflow issue however remains the total absence of a proper preview renderer. Back in the day when I used Lightwave the appearance of FPrime and the ability to preview my scene in almost realtime improved my lighting and material skills by a factor of 10. Trust me, once you have ever experienced using such a thing, you will not want to live without it. Some will argue that of course the program has an interactive render region, but it’s not the same. Since it’s just the conventional renderer constrained to a specific area and running in a loop, the limitations are just the same. It can take forever for anything to show up and you still can’t navigate your scene interactively.

Of course exactly that kind of workflow is possible in modo and ever since the introduction of RayGL in 601 even available to a degree as a normal viewport (you could always use multiple Preview windows in the past already aside from this). This makes tweaking parameters for lights and materials a pure joy. Since it’s integrated fully in the rest of the program, naturally you can even use it to preview animation and with all features full on. Even global illumination will preview at acceptable speeds and specific features like hair or particles will show up correctly as well.

As is evident by this, modo makes it a point to properly integrate everything to impose as few limitations as possible. This is achieved by making everything raytracing ready, including NPR rendering for instance, in favor of using specialized renderers or post-processing effects. One of the advantages of that approach is that everything works with everything, giving consistent results, and that in the long run even custom stuff can benefit from enhancements in the rendering core. If. e.g. one day global illumination got even faster, the hair stuff would simply inherit those routines. One of the areas that could use some of those optimizations is definitely the volumetric rendering. Some of that just takes forever.

One of the biggest criticism with modo‘s rendering and material system is the material editor. It’s one of those “looks good on paper” things to most people now. The problem here is, that its attempt at mimicking the Photoshop layer palette and applying material on “masks” works reasonably well for small scenes with only a handful of materials, but gets pretty messy when you have many of them and each of the materials has multiple textures in different channels. A conventional material editor or a node-based system that integrates with the Schematic View would be much easier. What also complicates matters is that values are based on physical units. This has the advantage that it makes those values independent from things like scene scale or specific lighting setups, but it takes a while before you actually know how bright 30 Watts per square meter actually are or how strong dispersion and absorption values in transparent materials need to be to produce a good rainbow coloring.

Quality-wise you can get good results pretty easy. The defaults are quite sensible for most render settings and defaults for lights and materials and it is usually easy to take it from there. However, once more modo‘s technicality strikes and instead of dealing with absolute values e.g. for rays per pixel, you tweak rates, ratios and thresholds and the program will then adaptively decide if and when to use which actual values. This can make you pull your hair out when you are trying to get rid of things like aliasing artifacts in fine textures. Some users also would love to see correct physically based materials in an unbiased renderer and noted that modo‘s materials don’t look real. That is of course totally subjective, because even physical materials can look fake when not adjusted right. I for one am quite satisfied with what I can get out of the renderer, though I’d never make claims to my representations of polished steel and sandblasted aluminium being 100% physically accurate. ;-) On a similar note, architectural people have pointed out that the renderer could do a better job at calculating the color bleed from colored walls and bouncing light that you get when using radiosity. This is again something I cannot verify, since I don’t do this kind of work, but seeing comparative renders e.g. with Maxwell Render there may be some truth to it.

Cinema 4D

Pro

Con

  • basic setups e.g. for logo animation relatively easy
  • Sketch & Toon still holds up
  • overall bad performance and rendering speed
  • render times can vary hugely even with simple differences in settings or during an animation
  • different renderers cannot be used together
  • no usable preview renderer
  • no physical materials
  • materials require a lot of tweaking to look realistic

modo

Pro

Con

  • render speed is very fast for standard use cases
  • advanced features like global illumination often have a limited performance impact
  • render times remain predictable even in complex scenes
  • interactive tweaking of all rendering aspects using Preview
  • material system supports texture instancing
  • settings based on physical units, so they are independent from scene scale and complexity
  • material editor feels exotic and takes a long time to get used to
  • render settings are difficult to understand
  • radiosity could use some enhancements
  • energy conserving materials are still not necessarily physically correct
  • volumetric rendering can be extremely slow

Data Exchange and Pipeline Integration

In this day and age artists use a multitude of tools to produce their imagery. Not only is it almost always common to refine a rendered image or sequence in image processing or compositing program, but also many additional 3D tools can be involved in the creation of an animation. 3D trackers could have been used to reconstruct camera motion and scene data of actual locations, external simulation tools may have been involved in creating effects for water or fire, characters and assets may have been created in a 3D sculpting program or modeled in another tool, animation may have been done using motion capture. Therefore it is crucial that programs are able to import and export 3D data as well as image data in a variety of formats.

Traditionally, Cinema 4D has been able to ingest a number of legacy formats such as 3DS, OBJ or Lightwave‘s LWO/ LWS. This is quite handy for me when I need to go back to some of my old projects and use parts of them. The LWO format is also my preferred format for exchanging geometry e.g. from CAD conversions since it supports things like n-gons, multiple UV maps and can retain entities/ layers by putting each mesh on a separate layer. As one would expect, modern formats like FBX also import well. In the reverse direction things don’t look half as good, though. In 20 years Maxon have not managed to fix their poor OBJ exporter and you either need Riptide Pro or must take a detour through another 3D program, which by all means could even be the free Blender. The more modern formats are not without issues, too. As you know from my render tests, transferring FBX files created in Cinema is pretty much a pain. Axes orientations change and there seems to be a lot of extranuous (custom) data that prolongs the parsing process and may make other programs fail on import. I have made similar bad experiences with Collada, which just doesn’t seem to work properly at all, at least not in the programs I use. The only format that because of its simplicity not quite unexpectedly can be exchanged with relative ease is Alembic.

One area where Cinema has been quite strong is integration with post-processing tools. Of course it has a multipass system and it can either render files with layers  and custom channels (PSD, TIFF, EXR) or spit out each pass as a separate image sequence. It’s still an insider gag, though, that to date the multipass files cannot have custom file names and you are limited to 16 object buffers. One thing that made big waves when it was new was the After Effects composition export that allows to transfer 3D animation as Nulls, layers, lights and cameras and also serves as a quick way to build compositions from your image sequences. It is now being replaced step by step with Cineware. Ironically, despite my involvement with After Effects, neither of the two has ever been particularly relevant. The stuff I work on is usually too heavy or structurally convoluted and before spending endless time baking keyframes, placing Nulls and whatever preparations may be required, I long have just manually done what’s needed. And before we forget of course Video CoPilot‘s Element 3D plug-in also can use C4D files natively.

modo pretty much offers the same features for rendering images in a variety of formats as well as loading and exporting geometry formats, but does the latter part a lot better. Yepp, the files you export from modo, be it FBX, Collada or OBJ are actually usable in other programs without jumping hoops. For rendering the multipass system is also more refined in that it ties in with the material system. This allows you to create specific passes based on masking items/ materials/ selections and you are not limited in their number unlike with Cinema 4D. Even manual material overrides are easy this way. In addition to the standard shading passes several analytical outputs are available that can help to identify rendering issues or can be used for further processing in compositing tools like Nuke. For the time being, 3D integration with compositing tools is somewhat limited on the After Effects end and only available as a Python script. For Nuke thinks look considerably better since it can import OBJ files and there are tools to import FBX as well. The Foundry also already have demonstrated using modo‘s renderer natively inside Nuke. Whether or not this tech demo one day will make it into a final product is however at this point an open question.

Cinema 4D

Pro

Con

  • good import of 3D formats
  • probably overall best After Effects integration
  • complex multipass system
  • export of 3D formats unreliable and with technical issues; may require lots of manual preparation of the scene data
  • some unnecessary workflow limitations in the multipass system

modo

Pro

Con

  • 3D export works much better
  • Refined multipass system
  • limited 3D export to After Effects

The Future

Foretelling the future is of course impossible, but with regards to the two programs there are certain trends that are relatively easy and safe to speculate on. One of those is that both will very likely support “deep compositing” by ways of OpenEXR 2 in their next versions. Nuke already supports this workflow, so modo not doing it would make little sense.

Before making bold strokes with new features, Cinema 4D has a ton of legacy issues to work out and I would love to see some work on those. The lack of a unified simulation framework, caching system and usable UV tools as well as its clumsy material system are probably the biggest hinderances that keep it from being used more for certain kinds of work such as high-quality characters or visual effects. The renderer is another sore spot. I wouldn’t expect it to change completely, but obvious bottlenecks like the area lights should be remedied sooner than later. It’s just not at the height of times having to forego them when you are on tight deadlines just because they are so slow.

Despite already being at version 7, modo is still relatively fresh to the market and therefore naturally still has to learn a few tricks. Now that the basics for animation and rendering are all in place I would expect more work in the simulation department. Another thing that the program desperately needs is a realtime viewport that supports custom shaders for games. It’s a huge market and missing this opportunity would be foolish. It would also open up more venues for use in pre-viz or similar on films, where the program is already being used for modeling jobs and other tasks. Since I use modo for all my polygonal modeling it would also be good if this stuff was revisited in order to come up with snapping that actually works or better Boolean operations.

The Verdict

So which one is better? The simplistic and unsatisfactory answer would be: If you can, get both! That won’t work of course if you don’t have that kind of money.

I still see modo primarily as a complementary tool for other programs like being part of a modeling pipeline. When used by itself for everything it works best for projects that don’t exceed a certain size and complexity. Whether this is a still where the render quality and modeling are the most important part, a character model imported from a sculpting app and rebuilt for later use using the modeling and texturing tools or a landscape for a matte painting populated with hundreds of tree instances should not matter. I don’t see it yet as usable for complex character work or VFX shots where multiple animation types have to work together mostly for reasons of the interface still requiring some fine-tuning and the learning curve being quite steep for these tools. This is generally an odd split that you will feel when working with the program – modeling is fast, simple and intuitive, but many other tasks are difficult to do if you have limited or no prior experience in other 3D programs.

Cinema 4D is overall more accessible, but I tend to disagree with people that say it is generally easier. The thing is that anything you can do by just using some standard item types and tags sometimes indeed is quick to the point of being ridiculously simple. That, however, can change quickly when you need to deviate from this and create more complex stuff that may require you to think of workarounds to achieve your goal like having to get into XPresso. This is also something that will frustrate you as you learn the program in more detail and your skills advance. You may then bump into limitations that you didn’t expect like parameters of objects not being accessible directly and requiring you to learn Python. Just like modo I also don’t see it as a program that you will use to create elaborate VFX. As laid out in the previous paragraphs, there are too many limitations. One way or another you will then end up buying plug-ins like X-Particles or VRay to ease some of the pain. With regards to polygonal modeling it is of course possible, but not as elegant as in modo.

In summary I’d say that for now both programs have their typical use cases. In my opinion if modo can become more user-friendly and be a bit more procedural/ parametric, it has some great potential to make a dent in “the industry” as a whole. It already does some things that would be extremely difficult in other programs, integrates well with other tools and overall seems more focused on “doing things right”, meaning it feels more whole and different parts work smoothly together. Cinema 4D seems to be at some kind of crossroads. Some parts of the program need a major overhaul. It is still a robust workhorse, but also suffers from having gotten itself in a bit of niche, being the go-to motiongraphics 3D tool of choice. Being glued to Adobe now by ways of Cineware furthers this impression even more. In many areas it feels like it is trying to catch up instead of bringing something truly fresh to the table all too often. It’s sad to say this, in light of that I found myself thinking hard about cancelling my MSA quite a bit lately, but I’m willing to not yet give up. Perhaps R16 will really turn things around and then hanging in there may pay off.

About these ads

One comment on “modo meets Cinema

  1. Excellent read!

Comments are closed.

Follow

Get every new post delivered to your Inbox.

Join 44 other followers

%d bloggers like this: