williamgaylord

Boy, you'll have used up quite a few drill bits by the time you are done. I did re-roof my own house (nailing by hand), but that was only about 20,000 nails. I think Disney just glued M&Ms onto the original and painted over them. That is a tremendous amount of detail, but what a beautiful model. Perhaps you should use it to create a virtual tour. You could charge admission, or maybe sell it on an interactive DVD. Nice work!

When I had the ears made it was $50 per cubic inch, so a 4' long Nautilus might be a tad expensive. Their 3D printer has a size limit of 1 square foot--anything that will fit in a cube 1' on a side, they can make. They use ABS plastic, which makes for a very durable prototype.

Eric, I happened upon this web site that might interest you: The SubCommittee I was looking for pictures of this 18' "manned" model of the Nautilus: Pat Regan's Nautilus Not as authentic a replica of the Disney Nautilus as your model, though (the pasta bit is missing). And the interior is not what I would call "lavish". I'll be really interested in how you fabricate the brass model when you do.

I've had ear models made of tough ABS plastic using a 3D printing service by a company called Design Research & Development Corp: DRD Here is the thread: Ear Rapid Prototyping You might remember this thread, Eric, since we talked about your Nautilus model. William Sutton used a service called "3D Art-To-Part": 3D Art-To-Part Here is a photo of the ears I had made:

I'd say you did a great job at modeling and rigging. Looks very natural...if you can say that about a disembodied hand.

Interesting to examine the splinage of your work. Interesting how you intersected two loops at some of the joints. Judging from the renders it works well. Thanks for showing the splines!

This is an interesting diversion from your usual brilliantly crafted mechanical modeling. Looking quite good. About thumbs: The thumb has the only metacarpal bone that moves freely. It only has two "phalanges" (finger) bones sitting on top of that metacarpal. The other fingers have three "phalanges" bones each sitting on a metacarpal that does not move freely. The thumb and its moveable metacarpal sit on a carpal bone that juts out from the plane of the palm--like a little shelf that sticks out at a right angle to the palm. If you feel where the metacarpal of the thumb joins this little shelf as you look at your palm, you can feel that the thumb is jointed almost exactly in front of the index finger metacarpal--not to the side of it. You can also see that the joint is right near the wrist joint just a little to the right of the biggest tendon there at the wrist. If you place the model's thumb bone accordingly, you should get a more realistic movement of the thumb, and the palm will fold more realistically. Pretty amazing work consider you had to duct tape the mouse to the stump where your hand used to be attached! What dedication to the craft!

Thanks for the diagram. I found it so helpful I printed it BEFORE adding a post to this thread! A lot of this stuff won't be obvious even after a few rounds of looking at it. It takes time to get enough of the pieces floating around inside your head to be able to start seeing how they relate to each other. Diagrams like this sure help, though. Sometimes it takes a few episodes of dreaming about this stuff after staying up waaaaaay too late working on it. "Thanks Shaggy! I never would have seen it that way on my own. And the way you used Vernon Zehr's Terminato to demonstrate dynamic constraints was truly amazing....and Eugene's lecture on bones and Smartskins using Ezekiel's vision of dry bones really helped me make all the right connections..."

I could have seen it at the Atlanta Film Festival! Sorry I missed it! In fact, this year I missed the whole thing. I have to say though, your film would have been plenty of motivation to make a special effort to attend the festival this year. I should have checked the schedule on your website earlier. I'll be kicking myself for quite a while. (Thump!...Ow!...Thump!...Ow!...) Congratulations on your success so far!

Brilliant! Is this based on personal experience with cats, or have you been watching a lot of re-runs of The Planet's Funniest Animals? I currently have two cats who I know would react quite differently in this situation: One would scrabble frantically while looking ever so embarrassed. The other would simple go over the edge without any struggle and with a very round-eyed look of surprise on her face.

I have DiVX6.8 installed and Quicktime 7.5.5 and neither recognize the existence of the other, so I can't get the trailer to play. Quicktime will play the audio without displaying video. Windows Media player will display the video, but will not play the audio. DivX6.8 complains that Quicktime is missing and needs to be installed. Anybody out there have a clue what's wrong with the Quicktime/DiVX link? Correction: DivX6.8.2 plays only the audio just like Quicktime. So in Windows Media I could see the trailer and in Quicktime I could hear it. Beautiful work!

I updated to V15.0d and tried the render again. Identical rendering artifacts. So close!

The diagrams I posted earlier are a start. If I can squeeze in some time I'll expand on these and Yves can then critique these and suggest any corrections, improvements. I work for AT&T at their Atlanta, Georgia labs, and video technology is my main specialty. I think diagrams like these can help clarify what happens where without having to get too technical. I won't make any promises for time frames, though, since AT&T's IPTV has me spread pretty thin these days. This will be a good exercise for me to learn more of the CG world, since most of my experience is in television technology. What Yves has done a marvelous job of already is showing how all this translates into the art of creating the image you are after. The last diagram I did I would certainly change to emphasize that the display industry has currently taken the approach of standardizing display response to the 2.2 gamma curve, whether or not the underlying display technology's native characteristic follows such a response curve. Look-up tables (LUT's) essentially make the display's natural response appear to fit the 2.2 gamma curve so that any gamma corrected image data matched to 2.2 will display correctly. In the future with digital interfaces and build-in display "intelligence" it would be more appropriate to move the gamma compensation into the display itself, opening up a completely linear work flow right up to the display input. Today, however, we conform the image signal to match the display instead of the other way 'round.

BTW, I am really pleased with how fast this rendered! V15 Rocks!

Next I want to tweak the lighting. May try the Skycast rig again, which worked great in earlier experiments. Might be a good time for me to actually learn lighting in A:M and get familiar with OpenEXR outputs and post processing.

I'm posting the project file here so Hash can access it. Feel free to check it out, anybody, but just bear in mind that I'm reserving copyrights for a client project. Brownstones03.zip

Did a lot better, but still some rendering glitches when the leaves start to grow. I'll send a copy of the project to Hash and see if they can figure out why. Much better than previous tries! So close! TreeAndBrownstones01.mov

The animation is in the works! Tripped over a couple of querks in the import to V15. Don't know if I had the choreography length set wrong in the original, or it imported with a default length, but the imported project had a choreography length of 5000+ frames, rather than the intended 300. On top of that I did not notice that when I played out the animation, it only showed frames at large steps. The last frame in the playback was the last even step and the last frame of the sequence did not show--so the pose sliders that would show 100% only showed ~94% which corresponded to the last playback step. That threw me off and made me think the choreography relationships were messed up. Nope! Just a querk in the playback. Once I figured that out things have gone smoothly. I still have the small branches to set up, but once that is done I'll do a test render of the whole growth from seed to fully grown tree. So far so good!!

I'm thinking assembling in an action with the trunk as a proxy and the branches as action objects. But if multiple models can be used in a pose, that might be even better. I want to use the whole set as though it were only one model so I can use it in multiple instances (9 if I can manage it), rotating the tree a bit so it will effectively look like a different tree each time. Another option might be to render the tree in a separate chor and fake the multiple trees as flat video images (that will cast shadows) since they will be in a long, extra wide shot of a city block with nine brownstones in view. The end product is the important thing, so any effective short-cuts will be appropriate. I used similar tricks putting the "Plateau of Leng" image together for the "Lost World" contest last year, but this is more complicated being an animated sequence. Basically a brother and sister will be planting seeds along a city block and the trees will magically grow up as they work their way down the block.

You did so well for the contest I was wondering, "Is that little robot just composited into a photo?". Amazing work there, Stian!

I suppose since video cameras apply gamma correction, video file input gets a similar treatment? (Knowing how sharp you guys are it's a pretty safe bet the answer is yes, without even having to ask.)

The tree is actually a set of models: one "trunk" model and a set of "branch" models of various sizes. The branch models are constrained to the spline that guides the trunk growth when the tree is assembled in the choreography. I did it this way because the overall workflow was more efficient. Tree parts are simple, but there are so many of them! Coordinating the animation of all these parts was the real time killer. Easier to set up a "branch" model with it's own action and then replicate it. I change the shape of each branch by altering the splines that define it's shape. If I could do this iteratively to build a model I could do this in a single model. Otherwise a single model would require me to animate every single component--many hundreds of them. The model's animation is guided by a set of splines that define the final form of the tree. The basic building block is a spline path and a simple tube with a bone asigned to each spline ring of the tube. The bones of the tube are constrained to follow the path. I set up a set of sliders to control the position and scale of each bone/ring. An overall slider control controls the whole set. I build a branch by constraining the bone of each individual spline path to a point on the spline path that supports it in the tree. As the point in the "growth" of the supporting branch reaches the point where a new branch is located, the new brach's visibility is turned on and it starts growing. This all mimics the fact that tree growth happens at the end of the branches--once the branch form behind the growth at the tip is established, it keeps it's shape and just thickens over time as growth rings are added. Simple scaling of parts does not work, since that is not how a tree actuall grows. (That being said, I actually cheat at the last step by scaling the leaf clusters--but in that case it looks natural enough to work. Another compromise is that the tube stretches along the spline path, so the bark texture flows with it--in a real tree the bark stays put and just thickens.) So, if I could build a "composite" model from a set of smaller models, with all the constraints and controls remaining intact, I could build it as a single model instead of having to assemble separate branch models to make a tree in a choreography. It would be great if I could export what I animate in the choreography as sort of a "model group" with an overall animation control, so that, even though it is not a model, you can import it back into a different choreography as though it were a model. That might be more practical than an "iterative" model feature, since it would group a set of actions with the set of models. Yes, I need to work on that a bit to make it more natural looking. In reality, like branches, roots grow from the tips and thicken. In this case I should probably animate the shape of the spline rings at the base, not just scale them.

Now that I know V15 handles this very complex "model" just fine, I'll set up the keyframes and do a render of the thing growing today and give it a whirl. Then, if that goes OK, I'll put the brownstones back in and put in a better lighting setup. Stay tuned...

Not sure where the old thread is in the archives, if it's there at all. This is a render in V15 of an older project where I was trying to animate this tree growing from a sprout to a full grown tree. This is the full grown tree. This tree is actually a large set of smaller "branch" models assembled in the choreography. If I could assemble them as a single composite model it would be preferred, but I haven't figured out how to do that yet. I wish I could iteratively build the whole tree from a small number of tweakable branch models. Any ideas? Here is an early test animation with a scaled down version: Tree growth animation test. And a closeup: Tree growth closeup. Image attached is the project render in V15. Wahoo! It works without rendering artifacts!

I for one have a boatload of learning yet to do on this stuff. (Think "Titanic" when reading the word "boatload".) I think it would be great to have a new special topic on lighting/gamma/tone correction/color correction/HDR etc. (What category might tie these "image fidelity" related topics together? Rendering?) A good start might be pointers (in one easy to find place like a special topic) to some of the best tutorials we already have, including Yves' excellent collection of tutorials on these topics. Although my background is digital signal processing and video/audio compression, I'm a babe in the woods still when it comes to tone correction, color correction, CG rendering, lighting, image file formats, etc., that are the bread and butter of creating CG material. It might be handy to have an overview of what processes/data should be kept linear (eg., scaled instead of compressed) and what processes/data benefit from non-linear processing (eg., to compensate for non-linearities in display device characteristics) and the proper processing order for the best results. A wall chart might be a good format for such an overview. A trivial project--NOT! The Hash Forums in general have been a fabulous resource for learning a lot of this stuff and the generosity of many of the more experienced and knowledgeable members is something to be proud of, folks! Thanks a million!