The Untitled Thread Drift

[Vong]

Let me preface this by saying that I have not used A:M for quite a while. I do keep tabs on it though because it does hold a special place in my heart, I've still got a few buds around here, and I'm still seeing kick-arse art made with the program. Let's begin...

 

-----------------------------

 

CPU+GPU rendering was a way to increase render speed for the Cycles render engine inside Blender. Now that EEVEE is coming on the scene and is basically a game render engine, Cycles will probably be used only for specific tasks that EEVEE can't handle (yet), such as caustics, etc.

 

I don't know what went down when trying to get A:M to render on a GPU, or why there wasn't much of an increase, thus I can only speculate. If A:M is still converting from splines to polygon's at render time, perhaps that has something to do with it? (If you know, please inform those of us who weren't around! )

 

Would faster render times in A:M be appreciated? Sure. Nobody likes to wait for a render. I don't care who you are or what you actually say, you hate waiting, it's human nature. --Especially those that are on a deadline, whether client or self-imposed.

 

However, where they might make a difference is in all the iterative test renderings that we often do when testing lighting, materials, etc. on a scene. Now 5-10 seconds as opposed to 5 minutes for a test frame would be a valuable thing. We can work around this somewhat by doing lower resolution tests or rendering only a portion of the screen but sometimes you need a full frame test at final quality.

And this is where things like the Advanced Viewport in MODO or VPR (Viewport Preview Render) in Lightwave can come in handy. Turn them on and let the render iterate a bit to get an idea of your texturing/lighting. Something that A:M could use, but will most likely never get, again based on having to convert splines to polygons.

Blender and AM are very different in the way in which they are developed. Blender is a community effort with dozens if not hundreds of programmers. This is not true of AM.

Yeah... I think to get a lot of features added into A:M that users have asked for (even in this thread) would mean releasing A:M as open source and bringing in the hobby programmers to try and add the features. A:M doesn't seem to sell enough* to cover the cost of hiring 2-3 more programmers to add some of the functions. Steffen does a great job, but to cover what everyone wants, you need a small team. ^Do note, I'm not suggesting or pushing that A:M be released as open source.

Like John Bigboote says, he noticed huge increases in render time when exporting from A:M to Element3D.

Which makes me think that it's the converting of splines to polygons that is the issue with rendering in A:M. I don't know how the render engine handles things right now, but if it has to convert from splines to polygons for EACH frame before rendering, wouldn't/couldn't it be possible to convert the entire animation to a cache file of polygons and then render that out? Would/Could that make GPU rendering a more accessible feature? Again, all of this could have been looked at when looking into GPU rendering, I'm not sure.

And please, don't think that I'm saying rendering in A:M is a big issue, it's not. Rendering is what it is... And as soon as we can all afford the quantum machines that can render in real time as we think these things up will be the best day of all our creative lives!

Just to give an idea of what some former A:M users have talked about... Since the Big Exodus**, there are a few of us former A:M users that have talked amongst ourselves and said that if A:M ever went to a polygon based format, quite a few of us would return. A:M has a simple straightforward way of working. Does the UI/UX need some updating? Yes, but that happens to all programs (Just look at Lightwave). The one thing that us old users talk the most about, is A:M's animation tools. Some of its features were waaaaay ahead of the times and some programs today try to emulate or imitate, but still don't hold a candle to how A:M does it. So, if it were possible to integrate polygon/sub-d modeling, while still keeping splines intact as they currently are, you'd probably see a few old faces popping in again. You'd probably also solve some of the render talking points and probably be able to add all new functionality. A pipedream, but one can dream, right?!

Sorry for hijacking the thread...

* - This is based on an outsider looking in point of view. Looking at how active these forums are, as opposed to how active they used to be.

** - For those that started using/joined the forum after 2006 -- (Mako Voice) -- But that is a tale for another time... -- (/Mako Voice)

[Rodney]

if A:M ever went to a polygon based format, quite a few of us would return.

 

 

Vong,

Even if such a thing were possible I remain unconvinced and would guess that those in a position to fund such an important endeavor would be even less convinced.

 

The promise of a return rings hollow although it's certainly something I'd love to see.

It would go a long way to convince me personally if even a small number of those 'quite a few' were to demonstrate their stated interest and as a show of good faith simply purchase a one year subscription to A:M to demonstrate their desire to see A:M succeed. The worst that would happen is those devotees would spend $79 on a program they sincerely want to see succeed and that they hope some day will incorporate the features they need.

 

This will not happen.

We know that polygon/sub-d integration isn't important to those you speak of because as fellow A:M Users we have all seen and experienced their lack of interest first hand.

And unfortunately this is the underlying reality of that particular pipedream.

 

Perhaps if we start with one of those old friends and colleagues the ball will start rolling. Gotta start somewhere!

In case folks have forgot the URL feel free to share the link:

 

https://www.hash.com/store/

[robcat2075]

I don't see what it would get us. Would the spheres be more spherical? Would the purples be more purple? Would the characters be more charactery?

I don't see how.

[nemyax]

Which makes me think that it's the converting of splines to polygons that is the issue with rendering in A:M.

There are no "splines" or "polygons" at the renderer level really, just sets of point-based input data for the shading algorithms.

[John Bigboote]

I don't see what it would get us. Would the spheres be more spherical? Would the purples be more purple? Would the characters be more charactery?

 

 

The ice-cream might be more ice-creamerly! (one image made in A:M by me... other made and rendered in modo.)

[Rodney]

The ice-cream might be more ice-creamerly! (one image made in A:M by me... other made and rendered in modo.)

 

Looks to me like the difference is mostly texturing and lighting.

As long as I've been using A:M we have always been able to export a model out and texture and light it in other programs.

It's those other programs getting into A:M that has been the problem. (the sows ear to silk purse analogy)

[robcat2075]

 

I don't see what it would get us. Would the spheres be more spherical? Would the purples be more purple? Would the characters be more charactery?

 

 

The ice-cream might be more ice-creamerly! (one image made in A:M by me... other made and rendered in modo.)

 

 

But is that something you can only have in polygons?

[Rodney]

There are no "splines" or "polygons" at the renderer level really, just sets of point-based input data for the shading algorithms.

 

 

To piggyback off of what Nemyax has said here...

 

In the far flung past OpenGL itself ensured the point based data would be tesselated (into tiny triangles) but that isn't where this thing ends.

There is still a rasterization process that determines what data is rendered to pixels on a 2D screen.

But lets focus on the initial processs of tessellation first because what happens there defines what flows onward from there.

 

After the initial vertex shader is applied OpenGL dives into tesselation.

As of OpenGL 4.0 programmers gained the ability to assign additional vertices as GL patches.

So since 2010 programmers were no longer strictly constrained to triangles and strips of triangles.

BUT this created a very different and significant problem in continuity of said patches as initially there is no continuity whatsover in these GL patches.

The tesselated patches are individual quad primitives with no knowledge of their adjacent patches.

 

 

But let's move on for a moment because there are other inequalities to consider.

For instance, it is important that processing reduce variation as much as possible because according to the OpenGL spec:

 

The OpenGL specification is not pixel exact. It therefore does not guarantee an exact match between images produced by different GL implementations. However, the specification does specify exact matches, in some cases, for images produced by the same implementation. The purpose of this appendix is to identify and provide justification for those cases that require exact matches.

 

 

Emphasis added

 

Therefore the reading of the OpenGL spec is highly recommended when considering OpenGL implementation and upgrades to those configurations.

 

Ref: https://www.khronos.org/registry/OpenGL/specs/gl/glspec45.core.pdf#page=657

 

 

Added: The lack of continuity in rendering isn't particularly problematic because the blending process of color shaders makes everything appear to be smooth and continuous.

Where we run into problems is with animation in that those surfaces must be interpreted and manipulated by various means generally not equivalent to animating with splines and patches.

On the plus side, there have been tremendous gains on this in the animation industry of late.

 

I do like how the OpenGL spec states the following as if they have a good sense for priority:

 

Each primitive is a point, line segment, patch, or polygon

 

 

Of course those of us that use A:M would very likely prefer the term 'spline' over 'line segment' but the are largely the same thing.

It might not be immediately apparent but in that sentence they are saying point, line, patch (or polygon).

The last of those three elements being the one of notable preference; patches or polygons.

 

[nemyax]

After the initial vertex shader is applied OpenGL dives into tesselation.

As of OpenGL 4.0 programmers gained the ability to assign additional vertices as GL patches.

So since 2010 programmers were no longer strictly constrained to triangles and strips of triangles.

I suppose you realise that the tessellation control and tessellation evaluation stages are performed at every frame, unless you employ some post-transform cache trickery. You might be better off precalculating your tessellated surface in the main program.

 

 

It's those other programs getting into A:M that has been the problem.

I don't think A:M users really care. For example, when I released the Blender-to-MDL addon, a couple of wows were voiced, and then everyone promptly forgot all about it.

[robcat2075]

 

 

 

It's those other programs getting into A:M that has been the problem.

I don't think A:M users really care. For example, when I released the Blender-to-MDL addon, a couple of wows were voiced, and then everyone promptly forgot all about it.

 

 

I think that is very cool but I don't know enough about Blender to even try it.

 

Can you be engaged to create other A:M things?

[Rodney]

I suppose you realise that the tessellation control and tessellation evaluation stages are performed at every frame, unless you employ some post-transform cache trickery. You might be better off precalculating your tessellated surface in the main program.

 

Having not programmed anything in OpenGL I have to say that I didn't know that but it makes sense.

I wish I had a better understanding of it.

 

I don't think A:M users really care. For example, when I released the Blender-to-MDL addon, a couple of wows were voiced, and then everyone promptly forgot all about it.

 

This is a good example of what I was suggesting in my response to Vong's post.

People state an interest but that interest evaporates for a number of different reasons even before the desire is voiced.

I was one that added my voice of approval to your Blender add on because the merit of the work was self evident. That and I tested it.

But those that clamored for such... where are their voices? The level of real genuine interest from those that state they need these things falls short.

 

As for A:M users (with an emphasis on use) there is going to be less interest because A:M largely supplies what they need right out of the box.

And since many/most don't use Blender because it doesn't add significantly to what they need it's hard to support.

Those that need to support it are those with the desire to use Blender and other programs with A:M.

Again, where are those voices of support?

It isn't the A:M users that don't care. They demonstrably do.

It is the non users of A:M that say they would use A:M if only this... if only that... but demonstrably will not.

 

I appreciate your Blender to A:M addon because I keep an eye on Blender and periodically download and try it out.

I tested your add on and it worked for its intended purpose.

But for those who really should care... will such efforts ever be enough?

I'm ever the optimist but I must confess that I have doubts.

[nemyax]

I think that is very cool but I don't know enough about Blender to even try it.

I might take a stab at LSCM unwrapping after I've tackled it in my own project, but I'm not promising anything.