Search the Community

As I dimly understand it... Z-buffered lighting works by rendering a depth map from the viewpoint of the light. Every pixel of that map is really a number that is the distance from the light to the surface point that pixel lands on. then when the real camera image is being rendered, every pixel is checked to see if the surface point it lands on is farther from the light than that same surface point is in the depth map. If it is farther, then that means some other surface is in front of it from the light's point of view and it must be in shadow and should not get the light's intensity added to it's surface color. Apparently this is usually faster than computing an actual ray form teh camera to the light. So why can't this process accommodate the Boolean cutter? I dont' know, but it doesn't.

Phil I misread your question. I thought I read that you were asking about cloth. My bad. Clothing a character for me is easier than cloth. So what I do is build a model at skin level. I then copy a section and paste and enlarge for clothing. I modify the new section such as shirt. Once I am happy with the clothing I then remove the mesh of skin under the clothing. Or use a pose to hide the mesh that is covered by the clothing. Robert has shown me a complete of tricks that enhance the clothing such as a edge material that highlights the clothing. Materials are incredible to help enhance the clothing. whether it is darktree material or materials from scratch they help cover deformation in an animation. I am just now scratching the surface of how to use materials.

SNAP! Those treasure chests are sneaky! Well done, Steve!

just tinkering and then noticed a small version of model on the surface not sure why or how it appeared... bubbles.prj

Yeah, I tried that but that five point patch to the left of your first X (which then extended to your second X) started to do that "hey your stretching the 5 point algorithm too far" thing; acceptable with lots of surface texture, not so much on a cheek. My philosophy was to keep five pointers as small and symmetrical as possible. If the price for that is eight extra patches, so be it.

One best? No. That's a big "It depends" question. I presume 90+% of all the models you see in the professional CG world are textured with decals (or whatever their software terms the equivalent of that... "UV Mapping") Painting a decal lets you put a detail exactly where you want on a model. The other significant technique is Materials (AKA algorithmic textures AKA Perlin textures...). Materials are handy for general surfacing. The BlueSky movie "Robots" was done with all algorithmic materials, no decals. However, I don't think they are as commonly used as painted textures are today. I like using materials. Here are a few of my images that use Materials... Materials: sky, hills, stonework, demon skin Decals: box, demon eyes, eyebrows Materials: sky, cave and rock surface, dinosaur skin Decals: "STATE", hair Materials: almost everything except "STATE", "DO NOT TOUCH", and the hair. Materials: Sky, woods, metals Decals: gravel, hair Materials: all the surfaces including the wood and chipped paint effects are Materials. Decal: can label That's a big topic. Whole books and classes are made about CG texturing. However, texturing is probably where A:M is most like other software in the techniques used.

This issue may not be fixable if it's an unavoidable side effect of how AO works but I'll submit it anyway. Here is a prog. render of the test model illuminated by a sun type light source. The model is a flat grey surface above which hovers four glass windows. Each window model (7 in. x 7 in.; 17.8 x 17.8 cm) is 4x4 patches surrounded by a tubular frame. The greenish glass has a 90% transparency. Each window is floating a different distance above the grey surface ranging from 2 in (5.1 cm) to 1/2 in. (1.3 cm). This is a final render(9 passes) of the model after you turn on AO = 100% with a sky blue global colour. Notice that the ambient light is still being partially blocked by the almost transparent glass and the shadow density increases as the glass gets closer to the surface. If you reduce the transparency of the glass, the density of its ambient shadow increases so clearly AO is sensitive to the surface transparency. But even at 100% transparent the glass still has a noticeable ambient shadow when its very close to another surface. Even stranger is a progressive screen render with AO on. This also happens in v19p. Embedded project is attached. AO_bug_v19pt5a_embed.prj

I've left a large poly model running for days and could never get beyond 30%. I've had success with installing Blender and reading just enough of the on-line manuals to reduce poly count and in some cases convert triangle polygons to rectangles (or quads in their jargon). The foot on the left is the imported prop and one the right is the .mdl converted from a reduced poly version. I find there's an advantage to having your template model in .mdl format in that I can easily isolate an area and eliminate the "snap to surface" choosing the wrong side.

After you import the Prop, you can put it in a Chor and model new splines there, I recall. Drag the Prop into a Chor. Create a new empty Model and drag that into the Chor. Select the Shortcut to Model, then choose Modeling Model to begin editing the Model with new splines. Snap to Surface (Shift + 9), which attempts to place new CPs on the surface of a Prop or other object already in the Chor was made for endeavors such as yours.

Had some fun with BioVision's bvh files and Animation Master! It took some time to get used to the bone hiearchie. Most files start with a T-Bone pose from where it is possible to catch the right IK bone and corresponding Orient & Translate. Then themodel will act a-like. Some trouble with flying splines as CP weights. For models with low polycount it is atracting as they have not that dense surface to be divided in.

Installers: Windows: Windows 32Bit Windows 64Bit SDK: v19.0 SDK UpDate 0007210: [Net Render] NetRender Crashes during startup (sgross) 0007216: [Interface] Clicking outside of Chor locks out Manipulators (sgross) 0007222: [Bones/Rigging] Deleting bone causes crash (sgross) 0007225: [_Other] Crash on v19 model load (sgross) 0007217: [_Other] Crash on load of old model (sgross) 0007214: [Interface] Accent color of Windows does not change window color of tiled windows in A:M (sgross) 0007213: [Particle Systems] Hair width over length is somehow repeated several times (sgross) 0007208: [Hair] Crash on reset of Hair Parameter (sgross) 0007137: [Dynamics] Dynamic Constraints broken (sgross) 0007203: [Net Render] NetRender nodes close with format error (sgross) 0007200: [Interface] NetRender interface spelling correction (sgross) 0007194: [Net Render] Actions render incorrectly in NetRender (sgross) 0007196: [Modeling] Crash on Copy of Groups (sgross) 0007195: [_Other] Crash after edit of Expression (sgross) 0007189: [Bones/Rigging] Crash on delete of multiple bones (sgross) 0007186: [Bones/Rigging] Path Constraint target list crash (sgross) 0007185: [Bones/Rigging] Bone name trouble (sgross) 0007184: [Bones/Rigging] Crash on Bone Drag (sgross) 0007162: [Rendering] Surface transparency causing Hair transparency (sgross) 0007188: [Sounds] Playing any audio in A:M sets system volume to zero (sgross) 0007175: [Plugins] Mirror Constraints not working? (sgross) 0007180: [_Other] Crash during Backup? (sgross) 0007181: [_Other] Crash on Revert (sgross) 0007179: [_Other] Crash while renaming Pose (sgross) 0007177: [Decaling] Crash while examining decals (sgross) 0007178: [_Other] Crash on PRJ close (sgross) 0007176: [Modeling] CopyFlipAttach adds unnecessary dot suffix to new names (sgross) 0007174: [_Other] Crash loading PRJ (sgross) 0007173: [Realtime] OpenGL3 Hair with textures drawn not correct (sgross) 0007172: [General] False rounding for float/double values (sgross) 0007171: [Realtime] OpenGL crash, if a scaled copy for the realtime texture needed (MipMap) (sgross) 0007166: [Sounds] Sound stops before end of play (sgross) 0007157: [Rendering] SSAO not working (sgross) 0007165: [Composite/Post Effects] Feature: allow Blur greater than 15 (sgross) 0007160: [Realtime] Fluid particle false shaded render after load (sgross) 0007159: [Rendering] Crash on render (sgross) 0007129: [_Other] v18 D Box PRJ no longer works (sgross) 0007155: [Rendering] Fluid Particles render as Camera Background color only (sgross) 0007154: [Particle Systems] Blobbies don't die, don't resize (sgross) 0007152: [Particle Systems] Can't Bake Blobbies? (sgross) 0007153: [_Other] Default Resolution in Camera settings: Change from VGA to HDTV - 720p... (sgross) 0007146: [Lighting] Use Front Realtime Light reverts to OFF after onscreen render (sgross) 0007142: [_Other] Reverting property in Chor doesn't * project (sgross) 0007147: [Materials] PRJ saves forces unwanted keys in Material instances (sgross) 0007148: [Rendering] Custom Frame list renders only first frame multiple times (sgross) 0007143: [Plugins] Simcloth doesn't simulate (sgross) 0007145: [Net Render] NetRender Memory Allocation Error (sgross) 0007144: [Images/Animations/Rotoscopes] EXR missing from allowed image import types (sgross) 0007139: [Rendering] Shaded/Wire Renders don't show "Show Grid" or Rotoscopes (sgross) 0007138: [Rendering] renders use CPU SSAO instead of GPU SSAO (sgross) 0007140: [Animation] Euler/Vector/Quat default selection not retained (sgross) 0007134: [Net Render] NetRender nodes get stuck on "Loading Frame" (sgross) 0007121: [Materials] Increase the viewport size of a material? (sgross) 0007151: [Particle Systems] Crash on change of Attribute to Combiner (sgross)

As a follow up to your 1st post Largento: Your screenshots of the anomaly look a lot like the "backward facing polys" option in your rendering settings is not selected and you may have some surface normals facing incorrectly in your model. I feel sheepish mentioning this since you are a Hash Fellow and know the software much more deeply than I. You stated that you haven't used the software in a while though, so I'm taking the chance to mention this.

I recall when radiosity renders took hours. Now it's a few minutes. I dropped some old models from the AM CD into my tiny house room lit with radiosity. All the lighting is just that one bulb light near the ceiling. Mach 5 Racer: BioBot: MotorCycle: Janitor of War: Space Marine. Something about the surface specularity on this model and the previous one is causing the conspicuous bright spots in the room ( I think).

The lighting definitely looks better in the above photo, the ceiling looks less sterile and more realistic due to the less perfect surface. If not for the CG character I might think this was a photo in an architectural magazine and not a rendering.

A ground up re-write just for ARM?... I doubt that can happen. Some years ago former A:M programmer Ken Baer told me that A:M has been rewritten from the "ground up" twice in its history. Both times it took six programmers about two years to get it to being stable and usable again. However, compilers are more powerful now than they were back then... Windows 11 on ARM gets big boost with rollout of ARM64EC It's not clear how much work the programmer has to do to to "recompile" for ARM, but maybe this sort of half-emulated/half-native is what could be done. Steffen is the expert, not me. I don't know if A:M runs on Windows on ARM or not. The Microsoft Surface Pro X is an ARM PC. I can't imagine them selling a PC that locks out all existing windows apps but then... a lot of their customers just run MS office apps and those have been made availabe in ARM versions.

Doug, In the Render settings you just turn "Plug in Shaders" ON, you don't set any particular shader. The two hair shaders only appear as options in the Surface Properties of a Hair Emitter and must be set there.

It's mentioned in this post... It's something you choose in Surface>Specual Render Shader

This does show up in final render but haven't tried rendering out a whole sequence. This model is being saved to disk and the spacebar has no effect. This happens only in Action or Chor (haven't seen it in model mode) and seems to happen only after scrubbing/tweaking skeletal movement a lot. Seems ok after AM restart but will re-surface randomly.

1-2-3... X-Y-Z 4... current spline tangent direction 5... tangent perpendicular to current spline tangent direction 6... perpendicular to patch surface

I've discovered a progressive render issue in v19.0p. While it's not a show stopper it's been annoying me for a long time and I've finally found the root cause. This image is an overview of the test chor. There's a camera with a 1000mm lens looking at five instances of a grey reference sphere, each at a different distance from the camera. The sphere instances are scaled in the chor as they get closer to the camera so that from the camera view they don't change too much in image size. They are positioned so the camera can see all five spheres side by side. Between the camera and the closest sphere is a slightly tinted, four patch plane that is a "glass sheet" with a transparency of 80%. It is positioned so that the camera only sees the lower half of the spheres through it. A simple sun light shines down from above and the chor has global ambience turned on with a white colour; intensity = 80% and occlusion = 100%. This image is the results of 5 pass prog renders and 9 pass full screen renders. The first two sphere rows are with no glass in the way while the last two rows have the glass turned on. For prog. renders through a transparent surface something strange happens as the surface gets farther from the camera. If you turn off ambience and leave in the glass slide this issue also goes away. Although it always happens in progressive renders, I have seen it occasionally in 9 pass full screen renders of an 80Mb project chor. So if Stefan does try to fix this issue he may want to look at both types of screen rendering. amb_occl_thru_glass_distant_embed.prj

My "Planes Trains Automobiles" Contest entry was an experiment in displacement mapping... The body of the car is just a simple spline form... All the surface details... the doors, the handles, the windows, the rubber and chrome trim... that is all made with displacement maps. There isn't an easy way to manually paint such maps in a paint program but it was easy to model the shapes on a flat plane. I put a white-to-black gradient on them and shot the arrangement with an orthogonal camera. That render to OpenEXR format was applied to the body to be the displacement map. I made maps that way for the front and back details also... I recolored the patches of that details model with white, gray and black to render versions of the map for Transparency and Reflectivity... A turn-around of an earlier WIP version of the car... 155Lefts_3500.mp4

Further development of our live Answer Time discussion Saturday... these use a displacement map to create the surface detail. Whoops!

If I import an STL file I am getting a lot of surface artifacts where the surface is not smooth, and I have tried adjusting the peak angle. When I export I have no issues. Anyone have any ideas?

I've thought of one more mistake I made... At 4:51 we see the SHIFT options panel for Bake Surface. I should have set "margins" to 0 so that the tile for each patch wasn't padded with an extra pixel. One pixel wasn't highly noticeable, but zero would have been correct.

Done some more work on Ursa. Finished rigging his cloak (except the hood) and added his staff (The staff of the north). I set the star fragments in the end of the staff to glow and tried to do a render. But for some reason, even though the star is the only thing in the scene set to glow, A:M is making the fur trim of the cloak glow as well. I even went into the surface settings of the fur and set glow to off, and the group that the fur material is assigned to and set it's glow property to off and the fur is still glowing. Think it might be a bug.