3D

Robotic lifeform (steam operated)

0
1898 days
by in 3D, All, Programming

In my valiant attempt to create a video game I came to design some levels, of course, and some enemies. Here is one of them, not looking specially mean. It’s a steam robot.

Robotic lifeform (steam operated)

Edit : ‘refined it, the front wheel is smaller, ‘like it better :)

Robotic lifeform (steam operated) Rev B.

Maya2LW Pipeline | Part 3

2
2101 days
by in 3D, All



Thanks to the precious info given by Lernie Ang I was finally able to convert the eyeballs. Now, I there’s just the eyelids left and the character will be completely translated from Maya to LW.

Sneak Peak Here

Maya2LW Pipeline | Part 2

0
2390 days
by in 3D, All

Here’s a quick snapshot of the texturing work in progress.

The eyes are still missing, here is how it turns out so far :

While trying to export a Maya scene to Lightwave with “MAYA2LW[2]” I experienced some issues with animated nurbs surfaces. So I decided to send an email to Lernie Ang, one of the authors (it’s an open-source solution) of MAYA2LW.
The answer was very interesting, here it is :


 Maya2LW2 was developed during a project that also used NURBS surfaces. this wasnt ideal at that time because i only introduced the idea of Maya2LW2-Poly-Only-Please to the modeler guy. it should have been done in poly. however, it DID work; i have had no problems with NURBS-to-Polygon conversion (with history, of course) at all. if it starts fine and then goes screwy after a few frames, i'm thinking of two things: 1.) OBJ *after* conversion must be reexported to make sure point order is correct, and 2.) ascertain that the poly mesh node was selected and not any other. this may or may not solve the problem. the reason why Maya2LW2 is a bit difficult to use regarding exportation is that it is hard (for me) to make assumptions about the complexity of a given scene. maya scenes can be super complex. if i had made assumptions about which mesh node to export it may not work 100 percent of the time. sometimes transforms share two or more shape nodes (e.g. two mesh nodes), which can be a bummer since Maya2LW2 will have to *figure* out which of them is really intended for export.

Lernie kindly sent me a link of another MAYA to LW solution : www.zdavu.com/dev/a2a

All this sounds like music to my hears, ‘got to test asap !!!!

Maya2LW Pipeline | Ten years in a cell …

1
2399 days
by in 3D, All

Maya2LW[2], screenshots of both applications

I started a collaboration with the animator Tim Linklater (who is running the excellent website www.strutyourreel.com).
I was in a desperate need of good animated characters and this guy had a lot of stunning animated stuff that deserved to be lighted & rendered, so we decided to join our forces. He sent me some of his pieces of work done in Maya, but I almost never worked with Maya. I had to solutions :

  1. Learn lighting & rendering in Maya
  2. Test the infamous Maya To Lightwave pipeline

I choose #2. I found 3 existing software solutions regarding this specific pipeline, then tried one :

  • Point Oven, an amazing cross-software baking system by Mark Wilson. It supports Max, Maya, Messiah, LW, XSI and even A:M to a certain extent
  • The Beaver Project, a Maya <-> LW pipeline used on many productions
  • Maya2LW[2], an open-source project. I took this one because it’s free and was recent enough to run with Maya6/7 & LW 7/8

Using Maya2LW[2] is very simple :

  • From Maya exporting datas goes into two steps :
    1. Save the mesh in Alias|Wavefront format (.obj) so that LW will be able to load them. There is no particular issue there, except if you have to export NURBS. Maya2Lw doesn’t handle NURBS, nor does LW. The solution should be to convert NURBS to Polygons, but it didn’t work for me so far
    2. Bake & export the animations. Maya2LW export ‘almost MDD compatible’ files, that just need to be converted to MDD format in order to be understood by LW. I had no problem here, except I had to select the relevant nodes in Maya, it can sometimes be tricky to find the right item.
  • Back to LW, I did it manually ’cause I couldn’t get the scripts working properly (version mismatch). It is rather straightforward, though :
    1. When imported, the .obj files sometimes comes without material/surface assigned. That’s a necessary step to reassign surfaces, so that you will be able to see your meshes in the layout. In this precise case, I had to refine the mesh a bit to comply the LW limits : no n-gons subdivision
    2. Apply MDD : I converted all the mesh transformations from Maya to LW with the MDD format, despite it is generally dedicated to mesh deformations (blendshapes, skinning …). LW uses the Motion Designer displacement plug-in to apply MDD files to any mesh. The settings are straightforward :

Maya2LW[2], MDD plug-in

Conclusion (so far) :

I’ve got roughly the same mesh & deformations in LW as in Maya. Roughly : it seems there are some slight differences regarding the animations, and the bug lost its eyeballs, guess why, they were in NURBS.
Got’ to find a workarround :)

Mental Ray | Illustration | Cloudy day

2
2426 days
by in 3D, All

‘Tried a “before the rain” render last night. Clouds are made of huge torus floating in the sky, with a simple “fallof” plugged in the transparency channel.

A wet “after the rain” rendering with lot of reflexions should be funny…

Mental Ray | Illustration | Ambiant Occlusion VS Global Illum.

1
2437 days
by in 3D, All

Lately I had the opportunity to test Mental Ray. In MR 3.4 I found “Ambiant Occlusion”, a shading tool that is becoming a true alternative to Global Illumination. Amb. Occ. is nothing new to CG, but it last implementation in Mental Ray comes with a lot of handy parameters :

  • sampling rate : quite obvious, will determine the amount of rays cast by the shader
  • spread angle : will make the probing from narrow to wide angle, thus more or less sensitive to the details around
  • distance : a critical parameter that define the probing range from near to far

Among them, Distance is a real breakthru against Global Illumination. Small probing distance make shorter render times (more than 200% in some cases). And it gives subtles areas of shadow.

Of course, it doesn’t take account of the “boucing energy” phenomenon. Fortunately that’s the funniest part of the lighting job : adding pointlights here & there to mimic the bouncing of light. That what I did in this scene.

In the end, hires render time came under 2 minutes (VS 8 minutes for a full GI solution with LW)

Mental Ray | Rusty Metal

1
2480 days
by in 3D, All
I was looking for some rusted metal shader for a scene I’m working on and I wanted it to be fully algorithmic, no bitmap at all.

The main idea is to have blurred reflection with some dusty bumps in the less accessible areas. This require several component to be layered : diffuse, noise, ambiant occlusion, blurred reflection …
I see many benefits in algorithmic shading :

  • small memory impact
  • no interpolation artifact
  • no more tilling issue

Here’s how it works, in pseudo-code :



 amb_occ = ambiant_occlusion("cone=wide","distance=small","fallof=high"); C = diffuse() * noise("grey","orange") * amb_occ; C += specular() * noise() * amb_occ ; C += reflect("blur") * amb_occ ;

Quite simple, eh ? :D

Render details (Mandarine)

1
2502 days
by in 3D, All

  1. Despite the very low amount of polygons, it is always possible for a model to catch the play of light
  2. Darker areas sometime claims to be colored. This can be observed with traditional medias, especially on sensitive color films
  3. Depth of field will blur the unwanted details, as long as the shapes remains readable, and will enable you to composite a texture layer

Doctor Atome, freaky sci-fi from 50′s

0
2503 days
by in 3D, All

This scene uses a strong backlight, as a tribute to the earlier sci-fi movies. The first step was to setup dark silhouetes on a light background, then add a backlight so that shadows will be running accross the camera, and eventualy recreate the bouncing of light to emphasize the characters’ features.

Fresnel reflexion created a slight transition around the silhouetes. An arealight casts soft shadows (but in this case a pointlight with sharp shadows will probably works as well), and spotlights here and there were usefull to trace the bouncing of light. Using radiosity here would have been hard to control and probably far less accurate.

To sum up I would say that playing with violent contrasts, orange eyes versus a dark head, helps to suggest a menacing robot.

Tank scene by day

1
2503 days
by in 3D, All

The modeling of this scene was very quick, for I wanted to focus on lighting, as always . It simply consists of some poles in a field, around a roughly shaped tank.

  1. The funniest is : there’s only one light on this scene that suggests a raising sun and casts rather long shadows. The blue backlight seen on the tank and the robot is pure reflexion of the blue environment. Eventually, I used a strong blue fog to give the scene its overall color and to strenghten the tank agains the background.
  2. Adding grass was an obvious choice to me, for it really catch the play of light.
  3. As the final render seemed too blue, color corrections on high colors proved very useful to achieve a warmer lighting.

« Previous
Next »
Go to Top