Jump to content
Hash, Inc. Forums

rodger_r

Hash Fellow
  • Content Count

    709
  • Joined

  • Last visited

  • Days Won

    15

Everything posted by rodger_r

  1. If you want to see that front projection set picture in colour and read all about 2001 vfx, follow this link. http://nzpetesmatteshot.blogspot.com/2015/01/kubricks-2001-one-mans-incredible.html Since the 40' x 90' Scotchlite screen and massive projection system (also shown) were too big to move, that set is on a turntable to allow different camera angles. If your interested, also check for a rare medium shot (admittedly very poor quality) of the 50 foot Discovery model. You typically only see the 11 foot model on-line.
  2. Wide assortment available here with prices proportional to resolution. http://www.1000skies.com/fullpanos/index.htm
  3. https://1drv.ms/v/s!AoFR-z6yKnmN1kVhp2AGpb620N_0 2 min. (90Mb) clip of locomotive and tender covering 1 mi. taken by a low flying drone camera. Music soundtrack is a jazz tune from 1930 called "Choo Choo". As an example of A:M animation it's just a repeating walk cycle with stride length so nothing really happens. It was just a test to see; 1) Will Netrender choke on a square mile (1.6 x 1.6 km) of scenery? 2) Can I cheat on the level of detail of the tracks and the rock ballast when the camera is not too close and are the transitions noticeable? 3) How much "passing meadow" can I build with just a material? There are flashes of it in the first half but a reasonable material kicks in for the last half after the close-up on the loco. 4) Does the smoke and steam withstand 2 min. of scrutiny? Adding trees and other details to the landscape is underway.
  4. Thanks the suggestions. I just might use them. Pretty straightforward; you have the original flat mesh and the imported deformed terrain mesh whose cp's are on the same XZ coords and unselectable. Then in the action you view the two at a very oblique angle so you can see one whole line of cp's. The posing of each cp in the Y axis to match the terrain mesh would be the perfect job for an intern; like being an in-betweener but worse since it requires almost no skill.
  5. I'm working on a continuous 2 min. "shot from a drone" clip of my locomotive traveling for 1 mi.(1.6 km) to check for smoke and steam dynamics/densities and various lo-res cheats on the stone ballast that embeds the railroad tracks. It begins as a long shot, moving to a close-up and ending as a "running along beside" medium shot. The surrounding countryside is made up of twenty-one instances of the same one tenth of a square mile mesh arrayed along either side of the track. To add variety to each landscape instance I plan on applying a different pose to each one. The left ten instances shown already have some poses applied. While I was styling another pose, mostly using Magnet mode, I thought this might be a good time to use the Terrain plug-in. It makes fine looking meshes but the only way I can see to get that formed mesh into an action is to add it to the original mesh model and then match that shape in the model's pose, one CP at a time - all 4096 of them; do-able but mind numbing. Anyone have any better suggestions?
  6. You are correct, I do mean the "aim steering" bone. Apologies for not sticking with my own naming convention..
  7. I don't think turning all flattened splines to mag = 0 would necessarily improve the accuracy of the decal and I'll back that opinion up with the following: When I was decaling the model of my farmer's coveralls I split it into front and rear sections for flattening with the vertical break at the side seams. I wanted those seams to be as even and parallel as possible. To minimize spline stretching during the flattening process, I rotated each cp individually using the neighboring cp as the pivot (left image). I still got unacceptable distortions at the edges where the unseen splines warped back to the unflattened rear section. In retrospect, I probably should have included the next neighboring rear cp in the flattened front and then not decaled those rear patches. Instead I was able to compensate for the distortion by increasing the flattened magnitude of each edge spline to 250 which gave my useable results (right image). So I'm guessing the spline magnitudes that yields the most accurate decal depends on your flattening choices.
  8. Now that I have a rigged driver, no more autonomous vehicles. The chor is identical to the one in the first post. There is a constraint target for each hand control and the Saucy rig does the rest. pickup_with_driver.mp4
  9. OK Robert, howzabout this? I paintshopped the real xray to rotate the fingers at their knuckles so they more closely matched my at rest pose. Then I moved all the joints in my model to match the prototype, shortened the last segments of most of the fingers and slightly extended the thumb.
  10. I did. I think that particular pose tends to hide the fact. But thanks for the suggestion Robert, because it motivated me to take another swing at the model. I concluded that the rake-like effect partially came from the fingers being too thin which may have been because this hand mesh originally came from the barbarian in Jim Talbot's Leopard Queen project on the Extras DVD. (He has elongated fingers and nails and his thumb nail seems to be oddly positioned). So along with a number of CP tweaks, I slightly fattened the fingers, shortened the pinky, rotated the thumb and made the knuckles and tendons even more pronounced. The best part was I stumbled across a useable bump map to add some skin texture.
  11. I decided it was time to get someone to drive my various vehicles. This guy will perform two roles. The first will be to drive around the pickup truck https://www.hash.com/forums/index.php?showtopic=48329 . With a change of hats, an added mustache and a pair of goggles he's ready to be a locomotive engineer. My thanks to Mechadelphia for the Saucy Rig. The skin and cloth textures were chosen to make a reasonable impression at a distance, so they tend to break down upon close inspection. The stretching in the coverall decals comes from only flattening and applying a front and rear decal. I suspect I'd get less warping if I had gone for left front, right front, left rear and right rear. But this good enough for an "extra" who happens to be driving the real stars, i.e. the vehicles. composite_a.tga composite_b.tga
  12. Sweet biscuits! You try to eliminate every possible variable to make Steffen's job easier and then I forget render settings. Thanks Robert.
  13. I've discovered a bug that crashes A:M v19.0 on my Win10 machine under very specific circumstances. Before I submit a bug report, I'd appreciate someone to check my work to make sure I'm not missing something. All required files should be in the zip file including the following image showing the chor layout (top view). Thanks Open displ_bug_test.prj displ_bug_test.cho shows grid_test_a.mdl within the camera's field of view while grid_test_b.mdl, located at X=550, is outside the camera's view both models are identical and have displ_bug_test.jpg decaled to both of them as displacement maps the chor uses sky_small.jpg for image based global ambience with intensity = 100 and occlusion = 100 performing a screen render of grid_test_a from the camera view crashes A:M to get a successful screen render you can do any one of the following turn off grid_test_b.mdl in the chor or re-set the decal on grid-test_b.mdl to be a bump map or re-set global ambience occlusion to 0 or move grid_test_b.mdl to an X value outside of the span from approx. 350 to 650 displ_bug.zip
  14. This is probably going to be too detailed for some but I'm trying to avoid the forgotten feature syndrome. I find that when I get comfortable with a new (to me) feature I tend to move on to the next thing with no documentation. When I want to re-use that feature sometime in the future (a month? a year?) I have to re-learn it all over again (I'm looking at you Stride Length). So this thread is mostly a tutorial for my future self. There's a zipped file at the end that some may find useful. In v19 Steffen added the ability to add a series of images to sprites so this seemed like an ideal time for my steam locomotive actually steam. The following image encapsulates everything I've tried so far which barely scratches the surface considering how many sprite variables there are. To improve render turnarounds I used a stripped down version of my locomotive and tender, just enough to get the smoke plume's shape, scale, colour and shadows to be convincing.The first smoke sprite image I tried came on the Extras DVD with the Particles tutorial. Using this image I learned that sprites only accept images with an alpha channel and that the image works best if the image's colour channel is just a simple grey field. Using this image I was also able to determine a simple way to get a parabolic shape to the plume emitted from a fast moving object. The trick was to have the emitters be a series of flat angled louvers within the smokestack which are aimed forward at about 45 deg. A high enough "Inital velocity" and a bit of "drag" yield a reasonable plume shape. There's also a conical force named "wind" constrained to the loco to further shape the plume, add some turbulence and provide a cross-wind so the shadows fall on the side of the tender. A web search yielded a number of smoke images that I thought were slightly more believable along with a 6 image series showing the development of a puff of smoke. These images are shown in the collage on the lower left numbered 1, 5, 9, 13, 17 and 21. It seemed like a 6 step evolution would be too abrupt to be believable so I used variable percentage layers in PSPro to generate in-betweens to get a three step dissolve between each original keyframe. To see if this was worth the effort I set up a test of just my smokestack with one emitting louver active and a strong wind. To "calibrate" my plume I generated 21 numbered images that were also colour coded in groups (red, orange, yellow, green, magenta, blue) to really show the distribution of the images. This is the center test plume labelled 21 frame distribution. Replacing the numbered image sequence with the 6 original keyframes produces the upper test plume. Using my 21 smoke image sequence produces the lower test plume. The difference is not obvious for a fast moving plume but it might be more convincing in a calmer environment. The image in the upper corner is a still from attached test clip. The locomotive smokestack uses five emitting surfaces. The front, left and right emitters use a material with the center image to the right of the still with a light grey colour. The center emitter uses the 21 image sequence with a medium grey colour. The rear emitter uses the bottom image and a darker grey to suggest the steam's self shadowing. The mp4 files is a 16 sec clip of my test locomotive including the initlal emission of the plume so you can see how its shadow develops. Considering how little I've tweaked all the parameters, the result is pretty convincing. smoke_frames.zip contains all 21 tga smoke frames shown in the image with alpha channels. As I said, in my opinion these work best as sprites if the colour channel is one or two simple shades of grey. smoke_frames.zip JF6_smoke_c.mp4
  15. To make that work I think you'd need a very high resolution tire so that there are enough cp's at every point of contact. It would be nice to be that accurate but I don't think it's worth the overhead.I typically run my cars slightly below the surface they're "sitting" on to suggest a flat contact area. I assume you mean automatic body and wheel movements based on the roughness of the road. I think you'd need reference bones that track the surface at each tire contact point and then constrain each tire axle bone to follow them. Meanwhile the body needs it's own surface tracking bone to which it is partially constrained so it averages out the roughness. Once again, an interesting exercise but this is a '53 Chevy pickup not a Baja dune buggy. If I need to show it's wheels bouncing over a railroad track, it's easier to key frame an action.
  16. I know there's a few automobile modelers on this forum, this thread is for them. While animating a car turning a corner on my city street back lot, I realized that keeping the center (black) bone of a model tangent to a sharply curved path only produces believable results for short (in the Z direction) models. When a longer object, like a car (or pickup truck), goes around a tight curve both the front and rear wheels do a lot of sliding with respect to the ground. After some experimentation, I have a suggestion that may require some (perhaps painful) re-working of existing models but will pay dividends if you want your models to turn tight corners convincingly and steer themselves in the bargain (eat your heart out Waymo). The first step is to move the model so Z=0 is located at the rear wheels. This is no big deal if your building from scratch. But an existing model needs to have all patches (easy), all bones, center of groups and projection maps (time consuming in my case) shifted. The first assigned bone, the steering bone, controls the axles, steering pivots and wheels (children of the axles). This bone, starting at z=0, is oriented such that it's roll handle aims towards the front axle. After this the chassis and body are assigned a bone for rolling. The steering wheel gets its own bone for rolling. After setting up your action for stride length and wheel rotation, you need a few more constraints. The front wheel pivots are set to roll like the steering bone at 100% scaling. The body bone rolls like the steering bone with 20% scaling (or to your taste) while the steering wheel bone rolls like the steering bone with 500% scaling (or to your taste). The self steering part comes after you drop the vehicle on its path and add a null to follow the same path. Adjust the ease of both the null and vehicle such that the null is always located ahead of the rear axle throughout the length of the scene. I set it near the front axle. Then add a constraint to the steering bone so it's roll handle always point at the null. The result is fairly believable vehicle dynamics; exhibit A being the attached 47 sec. clip. And this is before any tweaks to the truck's ease to make it speedup and slow down as you may see fit. pickup_steering_lores.mp4
  17. You're right Matt, it is cool. But in this thread from 2014, https://www.hash.com/forums/index.php?showtopic=44601&hl=render+nodes Robert stated that a subscription came with four nodes. Is it now only three? I currently have four instances rendering.
  18. Worked like a charm Robert...currently rendering with three (count 'em!) three cores. Fantastic! Will set-up desktop shortcuts as per Matt. Thanks.
  19. Installation was by the book. All files are in the same directory.
  20. This post got me interested in trying Netrender v19.0 for the very first time. When I started it I got this in the command window I got "Windows can't find..." error messages since render server_64.exe and render messenger_64.exe are in the V19 directory not my AppData\Local\Temp directory. Suggestions?
  21. It appears your working on a private residence with siding. If it helps your concept, I can offer fairly convincing shingles via two BitMapPlus materials for colour and texture.
  22. You might have more success if you treated every joint as a roll constraint as I did on my locomotive. Typically I've aimed the roll handle at the other end of the link. The downside is that "roll like" or "aim roll at" constraints may only get you so far. You then have no choice but to key frame the end of the linkage. But since your animating a recurring action you only have to put that time in once. I've attached an avi showing my result. one_rev_c.avi
  23. #1 & #3 are fairly obvious...extrude to a suitably small hole. #2 & #4 are candidates for hooks to four pointers. My rules are maximize symmetry and four point patches that don't have an aspect ratio that's "too" stretched. Use three and five pointers only when necessary since they are not always crease free.
×
×
  • Create New...