Jump to content
Hash, Inc. Forums

pleavens

*A:M User*
  • Content Count

    597
  • Joined

  • Last visited

Community Reputation

0 Neutral

About pleavens

  • Rank
    Pappy

Previous Fields

  • Interests
    Sailing <br />Motorcycle road racing<br />Golf<br />Kids and GrandKids
  • Hardware Platform
    Windows
  • System Description
    AMD Athlon 1400 - Radeon 9600 256 - XP Pro
  • Contests Won
    **

Profile Information

  • Name
    Phillip Leavens
  • Location
    Chehalis, WA USA
  1. Happy birthday, man!

  2. Happy Birthday!!! :)

  3. You may have looked into this already, but I thought that you may be interested in the results I got from a test of rendering trees imported as Props. This is a crude test with only basic diffuse color added to the Props. The same models can have image maps applied to UV's that should work in AM. (I have not tested this to be sure) [attachmentid=20421] There are 9 trees created from 3 Props in this image, yet AM rendered the frame in 45 sec (5pass with shadows 720*486) The process: 1. Create tree in Arbaro (export to OBJ) 2. Import OBJ in *lender (no fgons or mater
  4. Several suggestions. Try a test render in ver 13 using image based lighting and ambient occlusion. The AO will handle the soft shadows, as well as giving the vehicle surfaces a non-cg surface look and the IBL will provide the enviroment color variation needed to make the vehicles look like they "belong" in the scene. I would guess that render times may be fairly reasonable if you use a low AO setting and smooth it with motion blur. (in comparison to using a light rig) The only light you would need would be a "shadow only" light. Careful to use a copy of the set if you do t
  5. I usually have a camera setup that I like before doing the null, so using compensate keeps my camera aimed the way I want it. BTW, you can also use the same null to drive the lighting around with the camera. Phil
  6. 1. Put a null in the center of focus. 2. Scale it large for easy access. 3. Constrain the camera to "translate-to" and "aim at" the null. Turn ON "compensate mode" while setting each constraint. Now you can rotate the null around it's "y" axis and the camera will spin around the null at a fixed distance. (if you convert the nulls rotation type to "euler" you can just type in 360 in the "y" rotation property to set a keyframe for a complete turn. Be sure to key the "0" location first.) Sounds more complex then it is. Phil
  7. Looks like there were several things that might have contributed to the banding. 1. The scale of the "cloud" model was very different then the scale of the "profile" model. This caused the "cloud" to be very compressed to fit the action. 2. The density of the "cloud" model is probably much higher then needed for this usage of displacements, not to mention a greatly increased render time requirement. The attached project has the mods I made. As the cloud model was scaled down to match the profile, the materials gradient position no longer matches what you had and will have to be
  8. I've done both. And I get the same banding in each case. I've sent this scenario to Hash; hopefully they'll turn up something. If you want, I'll be happy to look at the procedural version of the model. Phil
  9. I'm confused, are you doing the displacement with an animated quicktime decal, or are you using an animated procedural material? Phil
  10. I'm using A:M to render the displacement maps and the compression bands are in the .TGA's that it produces. Is there any way to get around that? You can try running a "threshold" image adjustment followed by a gaussian blur on the tga sequence. That should even out the surface yet provide the displacement you want. Phil
  11. In the animated displacement tests I have done.. Animated displacement map stuff. I found it critical to use uncompressed video. The problem is that the compressed video will create slight variations of the grayscale value which will mess up your intended displacement. Phil
  12. Who's going to volunteer to update ALL the existing available models? I'm not trying to be sticky about this, it just seems like there's got to be a better way to go about it. That's why I made the "target" suggestion, it would be simple for users to select the null and set it to target the hand or whatever bone in their existing models. It should work with any existing rig that used nulls as targets to drive bone position/rotation. Of course, I may be ignoring a basic reason why it would not work. Phil
  13. Adding a new constraint to the existing system is probably more then most new users would be able to handle. Phil
×
×
  • Create New...