Unity Realtime Rendering

[Rodney]

Their 'realtime' render hardware is surely more advanced than mine but...

 

Here's the latest and greatest from Unity 3D who is demo'ing their latest beta via a short video titled 'Adam':

 

http://unity3d.com/pages/adam

[detbear]

This is why it's so important for more interest to be placed on exporting animation out of A:M. Just my opinion. But it is the future. If you've never worked with a real time rendering

engine before, it's hard to describe the power it gives in seeing your project and making important changes.

 

It's a wonderful experience being able to easily tweak lighting, shadows, textures(bumps) in real time. My experience with it can be compared to putting in a great movie and being able to mess with

all of the lighting and effects as you flip through it frame by frame. And what's even cooler is the ability to just say....."Hey...I think a shrub/ car/ etc. should be right there."...and add one in without having to

re-render.

 

I think it's a great opportunity to get in the door with these engines via A:M. But it needs to be a convenient and desirable process rather than "already do-able."

 

Long live A:M

 

William

[DZ4]

Is motion capture at all related to this? I remember motion capture involved taping a bunch of "points" to yourself and animating in "real time". Then Kinect came out and basically said that can be done wirelessly.

 

I don't see anything from that video that shows anything more than a pre-rendered animation.

 

I can see what detbear is saying. Right now, you can play an action in shaded mode and tinker with the properties, bone movement, or whatever in real time, but it's usually a mess, and the need to go back and make adjustments is still there.

 

When you say "Real Time", it implies to me that you want to have an animated character that you can display in a format over the internet and communicate in some fashion. Like Twitter with visual, or Skype with a mask. I suppose if you're in the movie business or something similar, you would probably laugh at my naïve take on this topic, but it reminds me of Civil3D being the most biggest [bad grammar on purpose] thing to hit the Civil Engineering industry, when it's just BS.

 

It seems there would be too many things to have to adjust in real time to make it make sense. Are you thinking of making a 1.5 hour movie in 1.5 hours? That's feasible if the plot is to take a day in the life of John Doe and make a film of it, I suppose.

 

I think you're going to reply with an explanation that it's an editor.

 

But I can dance better in real time by a long shot than I can actually animate it. So I'm pretty interested on anything you got.

[Rodney]

You make an excellent point Darrin.

What exactly is 'real time' rendering.

I don't think any of us believe that the short film at the link is actually playing in realtime... only that in some way it was pre-rendered in realtime.

Still, I'm going to guess there is some optimized code that makes the most out of the latest and greatest in graphics technology (real time or otherwise).

 

Is motion capture at all related to this?

 

 

I haven't seen a behind-the-scenes yet although I expect just such a thing should show up on FXGuide shortly.

At a guess I'd say the performances were motion captured and stored, tweaked and readied for playback and rendering. Materials and lighting then tweaked to optimize every possible calculation and the the real time renderer was turned on. How did the imagery get from display to harddrive? Not sure. I assume they didn't just screencapture the whole thing so what we are seeing probably can't be called realtime rendering. I must assume that an equivalent is playing back on computers somewhere for demo purposes.

[detbear]

Rodney....It is of course rendered to a final file, but the pre-rendered work environment is amazingly close to what you see in that final render. Much like the Marmoset Toolbag Environment. And it is enhanced by the

amazing strides in Video Card tech. However, "latest and greatest" doesn't mean you have to have a beast of a machine to use it. It might not run quite as optimally for a lower machine, but it still works better than last gen

methods. I have a middle of the road system and it works pretty well.

 

The animation process is secondary to the renderer in this case. Whether it is in fact mocap or hand keyed is not the issue for me. You can import Mocap or keyed frames

and it's still used the same way in an external engine. The world(props, backgrounds, etc.), the lighting, the effects(rain, snow, god-rays, are seen and changeable in a more finished state.

This allows the artist to see things as they are working on them. Not the animation itself. That is obviously done.

 

If you're familiar with Marmoset toolbag, it works similar to that. You don't model a character in Marmoset, you work on the modelled character....Here's an example:

 

xhttps://www.youtube.com/watch?v=1mY--K0-GGo

 

Similarly, in a real time engine, you would import animated mesh and work on the world/ shot/ there. In that environment, you can change, adjust, add, etc....while seeing the results in

a close to finished state.

[DZ4]

I noticed the models didn't move in that video, but obviously were 3D meshes with effects applied with a 'not so sure how done' background. Not that it didn't look better than A:M's Shaded View when modeling, but it seemed focused on creating a background with realistic lighting to match how the character (or gun) reflects light, with several other factors involved (understood) at the same time. Seems to me, an object (ie. model, character) is being rendered on a "layer" on top of the background with the same lighting effects applied, like green screen with lights in one location matching the other. The software looks very similar to 3DStudioMax as well, which I believe is Autodesk which would make sense as far as using layers (AutoCAD uses layers extensively to draw things on top of others for viewing clarity).

 

3DStudioMax was big on polygons and that's an issue when exporting objects from A:M. I think AMTex worked well for DirectX files, but there is the issue of how 5-point patches (and tying a spline into another without a control point...sorry my vocabulary has been in the attic for awhile) without showing up with gaps. Your software apparently uses a file to represent a 3D object and render it. What is the file format? Is it OpenGL which apparently doesn't have a similar format as Xfile, rather utilize a class (notso simple java file in Android) for the object?

 

I'm not familiar with Mocap, but pre-rendered keyed frames would already have lighting applied, no?

 

A real time engine that incorporates pre-rendered work as well as 3D models is my goal, but since things changed to Android (or Ios), the next best one would be written in Java with OpenGL ES, imho. But since we're on the A:M Forum, how does an A:M user put their models into such a program for benefit. My interpretation is that their best bet is to render a character's animations with a flat (black) background. and the surroundings would be filled in by others? Character animation, again in my humble opinion, is the hardest part of it all. It's the "content" that is so hard to find in abundance. Create a character, sure, make it dance and sing and appeal to an audience, hello? Bone rotations, Muscle motion, keyframes, timed to a soundtrack that exists in one's imagination. Although, music that is "good enough" is fairly simple, until you need to time it to the animation it's created for.

 

I guess I'm just spinning my own wheels here, but I don't see what I want to animate until I'm hearing a good song. MTV was so influential before it became [crap]. Even though there were bad music videos, the concept adapts well to amateur

animators, as in a conceivable time frame to put forth something. If there was help to throw in a background, and just "ship it out", oh and throw in the music, it would be a better approach, I think, that trying to create that masterpiece that never gets done. Sort of put what's existing to exercise. Just throw that crap you got out there...

 

but... if it can be "fixed up" with a fantastic background? Until the best "real time engine" is at our disposal (one based on frame rate rather than max frames per second would be my approach), let's start sticking it on an app. Even if it's crap. Just to get started.

 

You would be good at promoting such a thing, yes? Done with "Real Time Technology" by [your company name here]!

 

Regardless. I need to make base models (without restraints) that can be adapted to share the same actions, but look different. And they need to be pretty, and worst case scenario, ready for the stripper show app. Or worse. That whole does art reflect life concept.

[detbear]

Hey Darrin,

 

In Rodney's defense(And I think Rodney is an awesome guy), I sincerely believe that he does well by sticking up for A:M's current capabilities. It cost much time, and much money to make these things.

ALSO....Rodney is always there to help so many people here...it would be ungrateful to take a bad approach to pushing any development that rubbed against things. THAT being said, I do feel that it is an

issue worthy of consideration to improve/ work toward a simple to use export that brings the "Brilliance" of A:M's animation into external renders. My opinion is that the current, doable exports are not easy to

use and they don't produce good enough results when they are brought into external engines.

 

 

Going back to your questions about lighting on animation to be exported>>>>>>

In my workflow, the final lighting would not be done until the animation data, props, and other elements were imported. Perhaps the camera data would also need to be imported.

 

Pre-rendered work would require your own personal flow.....perhaps a compositing situation. I have combined several renders from several packages many times.....but that seems like a

compositing job rather than a real time render item.