Rodney

For those who watch such things... LucasFilm and ILM (read: Disney) have open sourced their MaterialX code. What is it? According to the release: Here's the general spec: https://github.com/materialx/MaterialX/blob/master/documents/Specification/MaterialX.v1.35.Final.pdf It's an interesting read on many levels. The specific areas of interest (to me) include: LIghts, Collections and 'Looks' which relate more to the area where textures/shaders meet geometry. Two focus areas reserved by the specification are 'twosided' and 'matte' which address issues of rendering that are not commonly implemented. Those are welcomed areas of interest. Example code, etc. can be found on the MaterialX website: FWIW: One difference in MaterialX applications is said to be that of applying the geometry to the material rather than the material to the geometry. (See Look and Property Elements in the document specification).

A return to the classics!

It sounds like you'll need to request a new (that is... another) activation code.

Try removing the master0.lic file from your installation folder and then try to activate with your new code. The activation process should create the master0.lic file In other words, the old license may be preventing you from activating the new.

Thanks for that! Well documented and insightful.

I'm exploring an idea for the contest with initial doodling starting to form. Not entirely sure I'll stick with this one but it's a basic idea that can be expanded upon if I find myself with more time to add additional aspects. I think I'll forgo posting a WiP because I'm not entirely sure where this will go. Although, come to think of it that aspect of refinement might be a good reason to post a WIP. (I still owe the forum a behind-the-scenes for the last contest)

When you post the things you do it's always worth the wait so keep on keeping on David!

Posting this here mainly so that I can find it later. This has roughly to do with a few thoughts I have related to 'drawing with splines' (as opposed to click/extend) and maintaining curvature (as much as possible) as control points are removed from or added to a spline and of translating/converting raster/bitmap lines into vector lines/splines. https://github.com/ideasman42/curve-fit-nd#origin The guy who adapted this code (Campbell Barton) is well known in Blender/Linux circles. Original code is from Screen Gems, updated with insights from OpenToonz and further enhanced by Barton. The library is described thusly: A (related) command line utility for tracing raster images and converting them to SVG can be found here: https://github.com/ideasman42/raster-retrace

Here's yet another means of achieving a constant speed and rotation. It's not a method likely to be used often but has some advantages in that a keyframe can be used to target specific frames so that the rotation within a sequence plays out 'perfectly'. The method is one of Post Extrapolation. The main process is to set up a simple rotation consisting of two keyframes (a start position and a controller). The way rotations play out by default in A:M is that once a set rotation is accomplished the rotation stops. The default being to hold that value in the future. But by changing the curve method we can tell A:M we want that rotation to continue... to reverse... to ping pong back and forth... etc. So we set our first Y axis rotation key to 0 and the second to any number (as we will change it later by moving the actual keyframe). Then we select those two keyframes, Right Click and change the Curve setting's Post Extrapolation to Linear (Accumulate gets similar results but not quite). We can then see where the rotation will continue into the future via the dotted lines of the channel (that were plateaued off before but now carry on linearly into the future. In this way we can visually target a specific frame where the rotation 'ends' for all practical purposes and just make sure that ending isn't within the frame range... so our object doesn't suddenly stop rotating. This can be a quick way to test various rotations to adjust performance in light of the scene as a whole. For instance, we may have a spaceship in the scene we want the audience to focus on but still want a subtle turning of our planet to enhance our story. Of course this Post Extrapolation approach can also be used to purposefully stop a rotation with constant speed and rotation on a specific frame.

I would not have guessed you created that graphic with A:M. Good work!

What??? Grrr... I was just working on my 10,000th entry and... all for naught! Yikes. That's coming up quick. I'd better polish off at least one of those other entries.

That was very impressive. Well done. Congratulations on the accomplishment.

Looking good from here.

That's okay. We'll keep answering and answering and answering. At least it brings folks back to the forum now and again.

I can anticipate the answer (although not in any way officially). Nope. The imagery should be sufficient to convey the idea of 'summer'. If it doesn't... voting...at least my vote... will reflect. Conversely, if the image includes the word 'summer' and in no perceivable way has a connection to summer... well then...

Hi Rusty, Hmmm... if precision is required I would recommend using an expression. The key to rotation can (usually) be to make sure we change the rotation to Euler. With an expression you might not have to do that (I'll have to check). Edit: No we don't. The plus is that you are after a simple rotation where gimbal lock won't be a problem so... likely don't need to change to Euler. Try: Enter an expression on the Y Rotation of your object. Your 'constant' will likely be your frame rate so take that into consideration. Assuming 30 frames per second your expression might be =GetFrame()*30 Where you replace the number 30 with how fast you want the object to rotate. 30 would be rotating 30 times in one second so... way too fast for a rotating planet. If we want the object to rotate slower than 1 rotation per second then we divide: =GetFrame()/2 This would result in having the object rotate half way around in one second. This isn't to say you can't do this another way. For instance, because it's a simple rotation you could just rotate the object in an Action, drop that Action on the Model in the Chor and then set the number of repeats. In this way you can determine how long the shot will be in the scene and adjust the speed to taste (by adjusting how many times the object rotates or how much of a partial rotation is in the scene. I'll note that I almost always change the rotation driver to Euler as that allows me to specify the number of rotations in increments of 360 (360=1 roation, 720=2 rotations, 1440=4 rotations, etc.) The trick to changing the driver to Euler is often to change the setting to Time Based rather than the default but anything that establishes a keyframe should suffice to allow you to change the driver to Euler (via Right Click>Change Driver>Euler). And there are other ways...

Definitely reads as a graphics driver issue. I'd research that with respect to your specific graphics care and see if you can install an updated driver (or revert to an earlier driver) that will address the issue. As for using only 32bit... don't limit yourself unnecessarily... install both 32 and 64bit as you can use them as necessary as the issue at hand seems to be limited to that limited case.

This relates to some previous musing on devices that are 'constantly on'; something that is fairly common now that wasn't all that long ago. The term 'pre-record' can be a little hard to research online because of the use of the terms such as 'prerecorded' which imply video recorded for later viewing. This aspect of pre-record has to do with cameras/sensors that record continuously so they can time travel into the past from the moment where the user of the device first hits the record button to retrieve data. Generally, 30 seconds of video footage can then be recovered prior to the moment the recording was triggered. A downside of this in first generation models is that only video imagery is continuously recorded (i.e. no audio) so this results in the first 30 seconds of a video being silent. This has been problematic for many police body cameras because the event desired to be recorded (both visuals and audio) may have occurred just prior to the device being activated (which prompted the officer to start recording in the first place. This deficit has been mitigated in a number of ways and continues to change. What this and other technologies point to is the ever increasing world of recorded data, How much is stored and how long it is stored depends on available storage and the desires and requirements of the operator(s). Combine this with a host of other technologies now redefining what a camera is and how it processes imagery and the future is set to be very different from what was only recently imagined. It has been said that to be truly revolutionary a technology must redefine our perception of time and space. Video pre-record, a simple technology at it's core, may not be quite all that but through it nascent 'time travel' capability suggests a world on the precipice.. Added: The term used for this technology is often "pre event recording", which doesn't quite capture what is going on either.

Nice one!

Thanks for the info!

Nemyax's conversion through use of Blender produces the best results I've seen to date. It is surely a gross oversimplification to say this but success appears to be largely based on Blender's access to SubDiv routines. At a guess I'd say this subdivision process is the critical middle step in converting polygons to splines** and one that needs to be accomplished no matter what conversion process is attempted. Martin's old saying of "You can't turn a sow's ear into a silk purse." remains just as true today but with proper processing a reasonable facsimile can be created. **Perhaps Nemyax can provide an overview of the critical steps his conversion process takes.

Sounds good. I guess I was thinking that rather than running a closed loop around the CP we might just move back out to the nearest closed loop and use that as it is already there to be used. I can see that in some cases there might not be a optimal closed loop to move outward to so creating the closed loop will take care of that.

Not quite, although I see why you would say that. That's why I posted a copy of your attachment with green overlay to indicate where the true poles are actually defined. You have extended those poles and connected various splines with the other sides of the pole but that doesn't change the value of the 'true' poles. The poles are indeed at the root of the problem. Added: Perhaps a better way to look at poles is to think of them in terms of continuing inside the shape and connecting with another pole elsewhere on the surface of the mesh rather than being a terminal point. For a far flung solution to the problem (although not one solved anytime soon) one might look to splines and patches that have thickness (two sided) because as they are placed they would always retain their continuity. Then when encountering an opening the topology is resolved by determining which surface will be inside and which outside when the hole at the pole is closed.

The scaling approach is the method I find optimal as well. An algorithm that approaches this might sample spline continuity to flag those splines that are continuous and self enclosed (i.e. their start and end points are at the same location). The spline loop nearest the target identified for closure would then be used to scale from. Backing off to the next closed loop also can suggest other approaches to closing gaps that utilize four point patches. I note also that we only seem to have this problem when the number of terminating CPs/splines is odd. If even, then the area can be dealt with using four point patches. I note that in your attachment all of the cases are odd (3, 9, 5 and 15 respectively) . This also suggests another approach to solving the problem which is to add another spline to the mesh to make the number of terminal points even.

I don't use SSS much these days but if repeatable that definitely needs a report.