robcat2075

Yup, Render Presets are new-in-v16 feature https://forums.hash.com/topic/50199-v19-v18-v17-new-features-and-enhancements/?do=findComment&comment=424030

Users will need to set A:M to "Tools>Options>Rendering>Use Settings from>Camera" which is entirely doable if they have been alerted. For future reference, Render Presets are saved and loaded from the Render to File Settings panel. Preset snapshots every render parameter. They are useful for migrating settings to a new camera, saving favored settings, and most especially, taking settings to NetRender which does not seem to have a "Use Settings From:" option. EXR stores pixel info in a variety of floating point formats rather than 8-bit integers. It permits values that exceed pure white (AKA 1.0 or 255/255) or that fall below 1/256 to be accurately preserved. This allows extreme adjusting/correction of levels and color in post without the banding artifacts we get from integer formats. It's possible for an EXR environment map to have an image of the Sun that is as bright as the Sun in comparison to other parts of the image. EXR also has numerous options for compression including ostensibly lossless ones. And many other wonders. A:M "Composite Projects" can work with OpenEXR but the workflow is a bit dense. I'll note that A:M can render to 16 bit PNG which will also give you increased processing latitude, although it still doesn't handle values greater than 1.0

That looks very cool, Joseph! I was 8 when "2001" came out. When my parents announced we were going to see a science-fiction movie I thought they were insane. We're going to watch a guy in a rubber monster suit? And what is "2001"? Is that like "007"? But the movie was absolutely astonishing. I was building cardboard-box spaceships with robot arms in the basement for years after that. Suggestions: -Could you save a render "preset" from the render settings and post that so we can use the same? -Banding... you may be able to reduce the multipass banding by using a slit with soft edges. That could be done with a transparency map for the slit instead of a modeled slit. -Exposure... If you render to OpenEXR and have an OpenEXR-aware post app that will give you enormous room to tinker with levels without having to get it exactly right in the render.

Previous topics in our forum banner. Click on any image to go to the topic. 2024

John could you save a Render Preset after you have made all your render settings and post that file here so i can try a render with your same settings.

Cityscape with AO, Fog and Radiosity. The Radiosity is a very slight effect in this case.

In the Radiosity example, I set the Intensity parameter very high...200... so that the effect could not be overlooked. Lower values are probably more typical in careful lighting situations. This compares several Intensities. Note that a 0 intensity looks just like a conventional render. The bottom row is the same images with a 1.8 gamma applied. These fine adjustments are where you want to know your monitor is carefully calibrated and that your audience's monitors are so also... which we never know!

There is some similarity in appearance, although the process is quite different. Here is a test scene. It is an open-top box with a sphere inside it. A single kleig light is above and behind the box. The camera is inside the box, pointing toward the sphere and back wall. A conventional render from the camera view gives this result. Every point in the scene is either illuminated by the kleig light or is black, for lack of illumination. Global Ambience (AKA Ambient Occlusion) simulates an infinity of kleig lights from every possible direction. This all-over light reaches more parts of the scene; the surfaces that are more exposed to it are more illuminated and the surfaces that are more "occluded" from it are darker. Some surfaces like the bottom of the sphere and the area below the sphere are still completely untouched by this light and remain black. Global Ambience ON, kleig light OFF: In both of the above cases, if a point is not directly exposed to some source of light, it is unlit and black. Radiosity (other programs call this "Global Illumination") works by calculating light that bounces off surfaces in the scene, as real light does. The blue wall, which is completely hidden from the kleig light , is still illuminated by light bouncing off other surfaces in the scene. Light bouncing off the red and blue walls spill some color onto nearby surfaces. The bottom of the sphere, although cut off from direct light, is illuminated now. Global Ambience OFF, kleig light ON, Radiosity ON: This PRJ has the three chors above. To render them properly, you'll need to do Tools>Options>Rendering>Use Settings from>the Camera AOvRadDemo005.prj

No, these were manually randomized. I do recall making a way to get a random value to set once and stick in a chor. That could potentially be used to drive the building heights but would be too random for this scene where I wanted to have taller in back and shorter in front.

There are really two light sources. The AO is set to 50% intensity and the sunlight ("Key") is set to 75%

Simple grids added for window details.

Cubes randomly scaled, Fog, and AO.

His artificial gravity is malfunctioning.

Looks like they over expanded and "Disney+" wasn't enough of a audience for the expanded output. I bet Disney+ gets sold off to Netflix or just closed in a few years. Too many streamers out there for the market. On the bright side, all the newly-unemployed can put "former Pixar" on their résumé. That will get attention.

@Rodney the latest update to Chrome has fixed the problem of John's GIF animation in the first post not showing up. Does it show for you now?

At the top of the forum is a banner of film frames highlighting interesting A:M work, which was a feature of the forum years ago but somehow got lost in a forum-software up date. Click on a frame and it will take you to the relevant post! New frames highlighting new work will will be rotated in over time. Thanks to @Rodney for creating the code that makes the banner work!

Yes, it is the latest official release. I keep v19.0 installed for when I run into a problem that is peculiar to v19.5. If you find something that doesn't work in v19.5 try it in v19.0 and let us know either way.

I just noticed the give-away includes VUE itself, the landscape generator. That's a big deal. But I get a download that is an .xls file... a spreadsheet? Does one need MS Excel to use this?

I have often wondered if particle emission rates are per patch or per group. Your test project is a good chance to examine this. First, however, I'll note that the two squares in the Chor are not quite equal. DenseMesh is about 100 cm across while SimpleMesh is about 150cm across then scaled down to 62%. Scaling an object will scale the particles it emits so that may explain why Simple has sharper corners than Dense... If I edit the squares so that both are 100 cm across and both 100% scaled in the chor, they are starting to look much more similar... The emission rate in the Sprite Emitter is set to "1000"... It's possible that is so high that an overload of sprites is masking any difference between the two results. I'm going to scale that value down by adjusting the Emission rate in the Sprite System. This value is always a percentage, not a count. Why are there two controls for... the same thing? It is possible to have more than one "Sprite Emitter" as children of the "Sprite System". For example a fire material might have a flame sprite, a smoke sprite and a spark sprite, each with its peculiar settings for many of the parameters we see in "Sprite Emitter". Having these percentage settings in the "Sprite System" lets us uniformly scale the whole effect without needing to edit each emitter. With the emission rates scaled down to 1% we can observe the sprites being born... Frame 0: Frame 5 Frame 10: Frame 15: Frame 20: Frame 25: Even though DenseMesh has 25 times more patches than SimpleMesh, both seem to be putting out an equal number of particles. This is the opposite of what I expected. I thought the number of particles would increase with the number of patches. I thought the lumpy result your original PRJ had for SimpleMesh was because it had fewer sprites to blend together, but it was really because they were scaled smaller and perhaps had less overlap among the sprites. Thanks for inquiring, Tom!

Your original question... how to do these morphing clouds in the fashion of my more recent clouds made with noise combiners... I'll have to think about that more.

there's a zip with a PRJ in this thread https://forums.hash.com/topic/41565-cloud-fly-thru/?do=findComment&comment=369290 A sprite needs to be custom designed for each shot to appropriately represent the light/darkness/shadow direction that matches the lighting in the scene, so the sprite in that PRJ will not necessarily work for another scene. I recall we did a Live Answer Time where we got a force to blow particles away from a shape:

As a first gambit, recall this test from several years ago... Those clouds are modeled shapes that emit one layer of sprites on the first frame, which then live for the duration of the shot. The clouds could potentially be any shape. Since they are sprites one could add a force and turbulence that slowly blows then out of the sculpted shape. For getting into the shape, how about another shot with the force blowing in the opposite direction, then reversing the frames so that the sprites appear to arrive at the shape rather than leav it? Then edit the two renders together.

MadFoxResplining.mp4

I haven't tried it yet but try this... Delete all the poses and do a test render. Is the spline problem gone? If it is, reload, delete the poses one at a time and test render each version until the problem is gone. That will give a clue that a particular pose might be the problem. Edit: see video below

First, try pressing the space bar to force a redraw. Next... does this still happen if you put the character in a chor?