Rodney

I find it a little amusing that there isn't much clamor for Stable Neo Hookian Flesh Simulation as of yet. It hasn't qualified as a popular buzz word or hasn't been promoted to the point where people deem it necessary. Give it a name that will roll off the tongue a little better etc. and it's sure to join the rest of the must have features in 3D software. On the surface this technology basically equates to gaining a level of performance mostly achieved through approaches like A:M's smartskin. This isn't to suggest that the improvements outlined don't go well beyond that of course but the complexity involved in setting up such simulations is hardly trivial. And that's why PIXAR is one of the few entities that can take advantage of such research and development and one could argue one of a select few who actually need it. The concept of skin moving over bone isn't particularly difficult to achieve but the preservation of volumes while doing so can certainly be challenging. At any rate, it would appear that PIXAR is finally catching up to A:M's smartskin and adding some new bells and whistles in the process.

As opposed to the less stable neo hookian flesh simulations... PDF and video are available here: http://graphics.pixar.com/library/StableElasticity/ Addititional info: https://en.wikipedia.org/wiki/Neo-Hookean_solid

The AV1 video format continues to move forward with support from all major browsers forthcoming and expected hardware to fully support the format by 2020. Here's a recent article that fills in some additional information and that reports on some of the competing technology: The article also captures some of posturing from those that expect to lose revenue due to the impending release of the patent free format. https://www.cnet.com/news/netflix-youtube-streaming-video-is-about-to-get-a-lot-faster-av1-compression/

Very nice Robert! Love the comedic timing.

Onward and upward... or... forward!

Also, if your model didn't have a hole in the middle you might be able to simply extrude and shape and then use 'Remove Internal patches'. The issue you'll run into with your current shape is that the process will likely get confused about which patches are internal and which are external.

I should have mentioned also that it is useful to change the offset for copy/pasting or duplicating to zero (0) so that the copy of the spline is at a known location. If you know the bevel needs to be at a specific distance from the original spline you might adjust the offset to that but understand that the Connect wizard will move the splines to connect them with a new Control Point if they fall within the wizards set tolerance. So, it helps to consider those tolerances and offsets.

Hi Bill, While there is no direct Bevel plugin or wizard that I am aware of there are several ways to get at what you are after. I will say that my primary method would very likely be to just stitch the bevel in as that is mostly habit to me. Depending on the layout of spline you might be able to use the Split Patch plugin... but I don't think that will be your best bet. The method I just tried that worked quite well is to use the Connect wizard. The process is to copy the spline that you want to have beveled and then place that where you want the bevel (I scaled it down slightly). Even better would be to copy that spline twice for use on both sides of the spline you wish to bevel. Then make sure the new spline(s) are as near as possible to where you want them stitched into the model. Then invoke the Connect wizard (which by default should connect splines with new Control Points where those splines cross. The tolerance can be changed if you don't want to mess with small tolerances. Forgive the cheesy attempt to replicate your model but here's an example of a spline automatically stitched into the model via Connect wizard in order to use it as a bevel: I uploaded the images in reverse order but in the second image you can see the selected spline that was copied and connected to create the bevel in the first image)

Tore, I hope you wont let this unfortunate event dissuade you from your enjoyment of using A:M. I'm sure Robert had the best of intentions in mind even if it did not come across that way. As for A:M reports, we all know Steffen is under no obligation to take on anything reported just as it is equally important that users should report what is of interest to them personally. Hang in there!

Don't forget that we can apply decals via the Chor windows too. Both of your methods will work in that way with the added benefit of stamping models from the camera view. And... the decal can be applied while in muscle mode too. The best way to get that done is likely to drag/drop the image from the Library or Image listing in the PWS directly onto the Model name/container in the PWS. The option to apply as Decal or Rotoscope will then appear.

I like him! (needs a blaster)

Mmmmm... looks like chocolate. Tinkering Gnome in Hawaii.... I'm not sure I can resist doing something with that...

Very interesting. Thanks for the deeper look. You've given us a lot to think about.

Very intriguing. Would love to hear more about your 'scanning' technique.

I thought the same until I experimented with the destructive powers of shattering objects with Bullet Physics. That alone might be useful in making props, effects and such. When shattering an object it primarily follows the groups assigned to the object so that could yield some artistically driven breakages. (That breakage is used in conjunction with the Explode_Rebuild Wizard)

Yes, if internally viewing icons inside A:M just updating the icons themselves is not going to fix a problem like that. The entire UI must be updated to accommodate SVG (or equivalent) icons. BUT... good news! It appears that the icon you are displaying is on your desktop and that is a function of the operating system so... that may be doable at our level. I recall someone once getting quite frustrated by the frequent updates to A:M and not having a different icon to tell them apart. At the time I don't believe he realized he had the power in his own hands to change those icons to anything he wanted. I have been assuming that Tore was talking primarily about A:M's internal icons but we don't want to leave the external ones out either.

Here's a test of a minimal improvement set where the current Navigation icons are just cleaned up. I'd have to check to see if the sharper edges are easier or harder on the eyes. On the left is current (Large icons) while on the right the a default level cleanup. Edit: What isn't particular useful here... when reduced back down to 'current' size the sharper detail looks like the original. So, I think it was already about as cleaned up as it could get.

As per usual I don't but my sense is that images are crisper if not slightly better lit (with minimal changes from the defaults that is)

You know... I even found that topic via search before but I didn't catch the part where you emphasize what is occurring while NOT using multipass. Since I thought it pertained to Multipass I moved on too quickly. Hmmm... yes. Something to chew on. Thanks Robert!

Here is what I call the Long Line of Icons. If someone wants to submit some changed icon sets I'll be more than happy to test them. That's them v v v Down There v v v They are rather tiny.

We could start with something easy. Here for instance are the Navigation icons. I've attached actual size and same thing blown up by 500%. Note that the underlying issue these days with screen resolution suggests that SVG images (because of their vector based infinite resolution) would be ideal but the current UI in A:M relies on bitmaps. So we have two ways forward at this juncture 1) update the bitmaps 2) Seek updates that support SVG icons in the UI. I'm sure you can tell which one will be easier to do. Added: Another reason why SVG is ideal (where it can be used) is for transparency which allows colors to change due to activation state etc. or color and tinting without changing the actual icon. My take would be to do both. Create the updated bitmaps and then offer the SVG for future implemention. It should be noted that the SVG icons should likely be the 'master' set even if not implemented because they can easily be edited, scaled etc. So, consider that a recommended format to use while perfecting the icon set. Aside: This is no small undertaking even if only the bitmaps are updated. A:M has a lot of icons! Added: This is the 'small' icon set. There is also a large. I'll try to add that here as well. Large set added named NavigationLarge.png Note that the only real change from what A:M is currently using and these images is the image format (changed to PNG so they can appear in this topic).

It's a good idea that should be pursued. There are some hurdles to overcome in this. The first is just the standard disclaimer type that there will be many and varied opinions on what the icons should be and what suggested icons appear to represent. I frequent another forum where their software has undergone some updating of UI, icons and whatnot and the most contentious tend to be.... you guessed it... the icons. It seems everyone has personal preferences that often don't match with other preferences. They seem to have solved that by primarily giving the job of deciding what will be used to one person who happens to be quite good at designing icons. This doesn't mean that those decisions aren't vetted and approved 'offiically' or considered for other changes. The second potential issue is that of using generic icons such as Googles (however nice they may be). Hash Inc very likely does not want to use any icon that cannot rightly be stated as belonging to them. In this arena it helps that A:M has some very unique iconic processes to go with the imagery/symbolism. Those standard icons (and the processes they purport to represent) can certainly be a great starting place. I say go for it. A:M already has some alternative icons that are never used buried in its code. If even one icon gets improved and all are in favor... mission accomplished. So much the better if they all get a fresh coat of paint. Added: There are other pitfalls that likely need to be considered in updating icons/UIs but those are enough for a token barrier of entry.

This is yet another one of those general topics where I'm trying to formulate the question but don't have enough to get that done. I note that in many of my renderings the initial rendering passes that A:M reports tend to render pretty quick (note that this is with and without multipass on) even on the order of seconds. The initial antialiasing pass can take about that same time. During the antialiasing second pass things slow down considerably (a render last night took seconds for each of the initial passes but over an hour for the second antialiasing pass). Now granted... there may be a lot going on there in that pass and some of it might might not specifically be related to actual antialiasing... although that's what it states is happening. Also... roughness of surfaces and shiny reflections surely added considerably to that particularly lengthy pass. I have no issues with that. But my curiosity is officially aroused and I want to learn more about how best to wrangle this second antialiasing pass and to better understand how to manipulate it. Any insights, pointers or references will be appreciated. Also as an aside: Over the last two updates I distinctly detect better renderings in A:M although I am not aware of any specific changes. It could be and very likely is just me and my aging eyes but I like what I'm seeing these days. And regardless, A:M still amazes me.

Truly bizarre and well told! Every time I thought I knew how things might end I adjusted... and adjusted... and... never imagined how the story was going to end. (I hadn't realized 'House Cleaning' was so close to release. Congratulations!)

Back to HEIF... Here's an article that digs more deeply into what the format is... and does... https://www.1and1.com/digitalguide/websites/web-design/what-can-heif-high-efficiency-image-file-format-do/