There are tools to go between the two (from http://cubic-bezier.com/ to Flash's HTML5 export), but I don't think there's any general solution to go from a UI like that, to code. What if one of your points is a programmatic parameter that varies over time? What if you're changing ground level with every iteration? How does the bezier-based editing UI help with that?
> What if one of your points is a programmatic parameter that varies over time? What if you're changing ground level with every iteration? How does the bezier-based editing UI help with that?
Check out how After Effects solves this, keyframed and scripted animation shares the same timeline and can reference each other.
Look and feel may not be copyrightable but this would make a lot of people very uncomfortable in terms of possible liability (UI's can be covered under design patents, etc).
I really recommend reading Creativity Inc. By Ed Catmull, one of the cofounders of Pixar. It's an incredible book full of insight on how Pixar fosters creativity to create hit after hit movie.
It really helped me shift my mind during some difficult projects where I felt like I was working against impossible odds.
I read the book. But it was after that that Mr. Catmull got caught apparently keeping is employee's salaries lower than market rates by making illegal non-poaching agreements.
Also, he never covered why Cars was so awful. (or Cars 2) which I believe both came out before the book? Maybe you disagree they were bad but rottentomatoes and metacritic has them near the bottom of the list along with The Good Dinosaur, Brave, and Monsters University.
I'd love to know what he thinks changed.
What I liked most about that book was how much he acknowledged luck. Examples: Luck they didn't get sold/disbanded before Jobs bought them from Lucas. Luck that Jobs was willing to blow 70 million on them as a computer company before they switched to being an animation company. And he acknowledges lots of other luck.
Cars is not a bad movie, it did very well, it was just a little below normal Pixar quality but still above most other studios work.
The good dinosaur, Brave and Monsters university all still good but not quite Pixar.
Cars two is an absolute disaster though and it's a shame it wasn't covered in the book. Something clearly went very wrong with this movie and they redid most of it in ten weeks or so I read, it seems to go against all the values and things they talk about and it does feel as if the story they tell about themselves is perhaps worked as much as the stories they make.
Cars was not critically successful, but it has been a merchandising goldmine. Every NASCAR mom and dad bought a Lightning McQueen, or a Mater, or other Cars toy for their kids.
> I see Cars as a film that appeals to children primarily, while the others are "family" movies in the best sense.
They're not family movies, they're movies that parents want their kids to be interested in but the reality is kids prefer Cars, Frozen, Shrek and Minions.
Finally went and saw Brave. And, I have to say, I was disappointed :(
Oh, the movie certainly had its good points. It was technically gorgeous - both the artwork and the character animation were Pixar at the top of their very considerable game. And despite complaints of the story being overly Disneyfied it was satisfyingly subversive[0] of many of the tired tropes it referenced. I didn't even mind that it was predictable[1] - fairytale movies tend to be, and that is often part of their charm.
No, what ruined it for me was that it was a fundamentally boring movie. The dialogue was bland, the humour was slapsticky (which tends to fall flat for me), the moralising was heavy handed, and there was no real tension other than that required for the linear development of the plot. Even the "jokes for the adults" that have practically become de rigueur for big-budget animated movies weren't all that funny (though I did blink a bit at the Wicker Man reference).
Ed is not the villain, and the agreements are not necessarily illegal. There is a lawsuit pending on the matter from the allegedly-affected artists. There was a DoJ investigation that was settled out of court. [0] You'll note that the settlement specifically refers to anti-solicitation agreements; i.e., the involved companies would not actively cold-call each others' employees. A lot of people seem to pretend that these agreements prevented employees from crossing over companies after they initially expressed interest, which they did not.
Such agreements are standard practice in many industries, and if they're actually illegal, it's due to a technicality in a law with which few are familiar (anti-trust legislation), not due to some naturally-apparent moral imperative. It's obvious that the executives involved did not conduct their actions with the intent of hamstringing employee growth, but rather with the intent of maintaining stable operations and keeping turnover low. It's completely reasonable to understand this as a normal part of running a business, especially considering that such agreements are common across industries.
Don't fall for the hyperbolic narrative from artist's trade outlets who are trying to manufacture rage to serve their own interests.
Cars 2 was pretty bad. I don't really follow reviews though so I'm pretty suprised when you say that Cars, Brave, and Monsters U did badly (I haven't seen the Good Dinosaur yet), as I loved all of them.
I was never a big fan of Cars, but I find it watchable. My young daughter loves it. Cars is one of those movies that really appeals to kids, and I didn't really understand that until I had a kid.
You really do get incredible insight into how they work up and tear down ideas in a setting that is both art and technology. Also fun to hear about lessons learned from iconic films such as toy story, finding nemo, and inside out.
I read that book and it was so good I immediately read it again. Then I read it halfway through again before switching to another book. Really great read and, oddly enough, a great book on leadership (especially in creative organizations).
I'll take this opportunity to ask: how do you learn 3D modeling? I tried just diving in with Maya and 3DS Max, but the tools are so complicated and I'm sure I was doing things the wrong way. I'm in college right now, but my university (UCSD) doesn't seem to offer any courses on the subject.
I played around with Blender when I was in college back in 2012-2013. Cycles render was just introduced back then. Blender and it's community has come a long way since then in this short span of time.
My starting point was http://www.blenderguru.com/ (for general tips and tricks), reading about ray tracing(for understanding why my renders were not up to the mark), anatomy of physical shapes(for sculpting) and watching a lot of behind the scene VFX breakdown videos(to understand their construction). Frankly, my humble computer back then was not capable of running 3DS Max or Maya.
Apart from this, a lot of articles regarding photography helped. A keen attention to detail and huge amounts of patience is required(while watching your renders take hours if you have the wrong graphics card).
Check out blender. It's a fairly powerful, open source 3d modeling tool (also game engine, motion tracker, compositor, sculpter, and more). I used to use it quite a lot back in highschool.
It also has a fairly high learning curve at first, but there's a huge community built around it[2]. Andrew price has some very high quality tutorials[3]
Maya used to have decent intro materials. With every version they would publish a physical manual with tutorials and walkthroughs. Most of my learning was from those materials. Honestly, none of the basics have really changed so if you could find either a digital or physical copy that might be a good start. I still find books work for me as a general overview for a brand new field (like Linux or web programming). Even though there's so much free material out there I appreciate consistency and cohesiveness of having everything covered in a book.
What sucks is they got rid of the Personal Learning Edition of Maya, so getting a legit copy just to learn isn't as simple. They do have a 30 day trial. Maya's documentation is still pretty solid for reference, just not for learning, so if you're curious what a menu or button does you can find out easily.
I think for learning anything new it's best to have a project like that "web-dev to 3d post" mentioned in another comment and focus on what you need to accomplish. I've also heard Cinema4d is a lot less intimidating to learn and has most of the basic things you'd want.
I also use blender, which has a reputation of being difficult to learn. I've used it infrequently for about 5 years, and I often learn a new way to make my job easier each time.
The blender communities my sibling mentioned are a great kicking off point with some high quality tutorials and resources. The blender wiki is also decent, but unless it has been updated recently, I tend to find it out if date. There are also tons of tutorials for learning the basics on YouTube.
Without having taken a 3D modeling course, I would say that following tutorials that teach both using the tool (blender, 3DS, Maya) and making basic models is a good place to start. From there, find tutorials to accomplish tasks that interest you: animation, texturing, organic modeling, rendering, etc.
This was posted here a few days ago https://levels.io/from-web-dev-to-3d/. The author was in a similar situation and found 3DS Max and Maya to be beyond his skill level. So he chose Maxon Cinema 4D.
I used AutoCAD in university and that is the extent of my knowledge on these matters.
If you're, say, coming from a more Adobe-centric background I'd recommend Cinema 4D and the Greyscale Gorilla tutorials. You'll ramp up plenty fast, and have some cool renders after just 1 day.
I've since switched to Modo (affordable indie licenses via Steam) but find both programs to be more modern and adaptive to my workflow than Maya and Max -- however, if industry standards are important to you, there is no avoiding the Autodesk Twins...
This is what I've done (albeit just messing around with it from time to time). I confess I used a cracked copy of c4d since a lot of the things I wanted to check out weren't included in any "lite" edition.
Not sure I feel great about that but I treated it the way I treated Photoshop and friends for years: cracked copies while learning and then at some point I was using it enough that I bought a legit copy of CS6 through work at a discount.
If I ever do more than fiddle around with C4D I'll look into buying a copy. It's just hard to come up with $1000 for the minimum version that supports global illumination (which I was trying to learn about).
Moral and legal issues aside, though, I found it a lot easier to learn than others I'd tried and it even made some other programs like Unreal Engine easier to learn.
I know Clemson University's Digital Production Arts teaches a lot of 3D animation stuff, they also offer student enrolled in the program a Pluralsight to learn Maya, Nuke, etc. I hear from a few of their students that it's a good resource compared to some of the coursework.
Hey, a couple of days ago, you offered me an invite to lobste.rs, but I couldn't respond to you, because your comment was not ranked highly enough. I would love an invite! Been wanting to join there for a while : )
my recommendation would be to try Houdini (http://www.sidefx.com). It is different from other 3D packages as it is fully node based (and not with a node layer added on top).
It has a reputation of being difficult or long to learn, but I disagree. I find it way more intuitive, as you can see step by step what is happening. Their doc also has loads of examples and there are nice forums to ask for help (http://odforce.net and http://www.sidefx.com/forum).
If you have a logical mind, it should appear straightforward.
From my little window in the industry it's indispensable for FX and simulation (water, fire, destruction), but the tools for modelling, texturing, and animation just aren't worth the time. I don't know anyone who uses it for that or would reccomend it for those things.
I've gone through their basic tutorials. It's really nice to make procedural reusable things (a ladder that will create rungs based on the height), but I can't even imagine trying to model something organic.
For feature films, the jobs are specialised, so Houdini does tend to be restricted to FX (although more and more companies base their lighting/rendering pipeline on it). But for commercials, it can happen that it is used in more departments.
I did commercials where animators where taught to use it, and that was a success in my opinion. They were happy because the animation tools are basically the same and the rigs were updated faster than they would be on other packages.
And it is true I've rarely seen models being done in Houdini. The only time I did one was for this commercial (https://vimeo.com/17808406), where the character is quite procedural. Had it been a more classical character, a Maya modeller would have done it.
It's good to see Suzanne popping up in so many places!
(Suzanne is Blender's monkey mesh primitive and logo. Blender uses it where other programs would use the Utah teapot. You see it in the character modeling icon on that page. Wikipedia about it here: https://en.wikipedia.org/wiki/Blender_(software)#Suzanne)
Twenty-four hours is not typical. I'm a bit out of date, but I think four hours is more common. On Toy Story, it was more like two. The increase is due mostly to the use of global illumination for nearly all scenes now. Renderman traditionally didn't do ray tracing or any other GI lighting. The modern version does, and it simple takes longer.
Higher resolution, and stereo (3D), are also to blame. Toy Story was rendered at less that 1080 HD resolution!
Is there more info about the TS1 re-releases then? Based on your comment I started looking for info and verified that the original render was 1536x922, but there's no info about the work they put into the 3D version and Blu-Ray release.
24 hours (wall clock, not CPU time) is a little long, but it's not unheard of.
With MC path tracing, the noise you get is pretty difficult to resolve, and a lot of companies are using denoisers afterwards to clean up the renders, as it's just not cost-effective to keep them rendering to that extent as denoising is faster.
> Twenty-four hours is not typical. [...] four hours is more common.
I'm in the industry, and [citation needed]. Four hours is not remotely typical for a final render frame, especially now that path tracers are the de facto standard.
From an answer on that page to a similar question:
> Renderman, what we use at Pixar, is also fast but for the quality we strive to achieve is very high, so we we squeeze as much as we can into it until it just becomes too slow.
So if the renderer became faster, we would just add more quality, and make it "slow" again.
That's somewhat true for VFX in general, but not really for Pixar: They mostly use procedural textures (they use them a lot more than most other VFX studios can) so texture IO is a lot less, and is one of the reasons they can get away with starting to use a GPU preview renderer (i.e. the textures fit in VRAM).
Regarding model complexity - that doesn't really matter these days - if you want to raytrace a scene, unless you want to do full-on deferred raybatching and geo paging (like Disney's Hyperion does), you need to fit the scene into memory, so other than at startup/ingestion time, model complexity doesn't really matter in terms of IO. Also, Pixar's base level subd meshes are really rough (compared to what you see in VFX in general - for VFX base levels are probably subdivided down 2/3 times more), so the geo given in in Pixar's case isn't actually that bad.
There's very little info in the Disney paper on geomapping, do you have any ideas on how they do it?
I guess that you don't want to page in full models (as you either need a very large amount of memory per thread, which means smaller ray batches, or you need to have a shared cache, which means waiting on other threads). So you'll probably need something similar to Toro (as described by Pharr et al.), which just doesn't seem very efficient to me (as grids have improved little compared to BVHs).
Easiest way is to have a two-level BVH, where the lower level just has overall AABBs of every object in the scene which contains a "geometryInstance", each of which then contain another object-space BVH of the triangles (or other primitives).
This is trivial to do, but you take a pretty big penalty for not being able to look down to the primitive (microtriangle, microcurve) level for the lower level BVH, so the quality of it isn't as good. So for stuff with hair on skin, you've pretty much got two objects overlapping which sucks for traversal performance. There is a way around this, but it involves storing a pointer to each primitive in the BVH which is expensive and mixed transforms / motion blur get complicated with this.
The more complex way of doing it would just be to use the single level BVH and partially build it - given the lengths Disney are going to in order to sort and batch the rays, it sounds like they can constrain stuff such as all rays they send in a batch are going in a similar direction anyway, so you can cull a lot of stuff.
These days in VFX we're pretty much just fitting stuff into memory anyway - there's no other option. PRMan does support geometry paging in theory, although Arnold doesn't and VRay only partially does (with VRay meshes), but performance absolutely sucks doing it, so buying more RAM is just the easiest/cheapest solution all round.
Disney are only really doing deferring / reordering to such an extent because of their love of PTex which sucks with random access IO, so...
Yup, I meant paging geometry. The problem with just doing a two level BVH is that some models can be very large, while others may be much smaller, which makes it hard to reserve memory for the geometry cache (even if it just fits one model per thread). Which means that you can store fewer rays in memory, and I'm not really a fan of constantly writing rays to disk. I was thinking of just cutting off subtrees of the BVH and storing those on disk, which makes it possible to assign just a few megabytes of memory to each thread for caching geometry. Not sure how efficient that would be though, probably a bit faster than rebuilding part of the BVH every time (especially when using high quality BVHs with spatial splits). Shouldn't be too bad with large ray batches, sorting and ray streams.
They do mention some tests with "out-of-core rendering of scenes with massive amounts of geometry" in the paper, but there isn't much info on it. AFAIK their patents mention streaming in geometry too.
I know that buying more RAM is probably easier, but it would be interesting to render very large scenes on commodity hardware. I guess paging in geometry is just too much of a hassle, you constantly have to stream in geometry to memory; to compute surface derivates, to do subsurface scattering, to sample arbitrary geometry lights, etc.
Why would you need per-thread geometry caches? That doesn't really make sense (memory duplication)...
What you'd do is just map the geometry + bvh into a serialisable format (like vraymesh) such that they can be fread() in one go pretty quickly. You could put heuristics in to not page out very small meshes...
But unless you batch and re-order rays (and I'm not convinced doing this is worth it if you're doing more than 3/4 bounces, as the incoherence just makes things a nightmare), there's no point really doing this (unless you're happy with very slow performance - even mmapping stuff is slow).
The per-thread caches are not strictly necessary, but you don't want threads to block because they can't stream in geometry to memory. You want some upper bound on the amount of memory each thread needs for geometry (each thread could try to ray intersect a different mesh). Dividing geometry into fixed sized chunks gives you this upper bound (max N chunks per thread).
Ray re-ordering is indeed a nightmare, but sorting very large ray batches (millions of rays) into coherent ray streams is less of a hassle, and it should enable coherent geometry access (which amortizes the cost of those reads, not sure to what extent).
But that doesn't really scale - unless the per-thread stuff is small (and then you'd have to page on a sub-mesh level - i.e. split up the mesh spatially and page it as you traverse through it for internal scattering or something), if you double the number of threads, the memory used for threads by doubling the number of threads will obviously double as well.
For stuff like hair where you need loads of scattering events or for SSS doing that (paging subsections of shapes) is just going to thrash any geometry cache you have unless they're quite big.
And I'm still not convinced by ray sorting: it means your light integration is extremely segmented into artificial progressions as you expand down the ray tree, and makes anything regarding manifold exploration (MLT or MNEE) close to impossible to do well.
Rendering is a trade off between time, quality and artistic and technical effort. No frame needs 24 hours to render; it just means someone wasn't tasked with making it faster or cheaper.
[1] https://www.khanacademy.org/partner-content/pixar/animate/ba... [2] https://greensock.com/timelinemax
I wish web devs would stop reinventing the wheel and just steal these UIs from animation software that are proven to work well for animators.