[HN Gopher] Cycles X
___________________________________________________________________
Cycles X
Author : Tomte
Score : 275 points
Date : 2021-04-23 16:08 UTC (6 hours ago)
(HTM) web link (code.blender.org)
(TXT) w3m dump (code.blender.org)
| vjeux wrote:
| When I was working on a ray tracer, I found that interpolating
| the color from neighboring points instead of leaving it blank for
| in-progress elements was a huge improvement for quickly seeing
| what the scene is going to look like. In the video examples it
| doesn't seem like they're doing it. I'm interested to know the
| rationale.
|
| (See "Progressive Rendering" section for an example:
| https://blog.vjeux.com/2012/javascript/javascript-ray-tracer... )
| zamadatix wrote:
| Cycles works a bit differently but the same general idea is
| supposed to be implemented via "CPU viewport rendering with
| Open Image Denoiser" which live denoises the rendering in a
| more advanced way. Unfortunately the video for that section
| doesn't seem to be set up correctly so you can't actually see
| it in action.
| amelius wrote:
| I wondered about the same thing. But look at the other videos.
| In some of them, the entire viewport is drawn at once and then
| incrementally improves.
| gmueckl wrote:
| What do you mean by blank pixels? Cycles is a MC path tracer.
| This means that it will always trace some paths that don't find
| high contributions to the final image. When this happens for
| the first couple of iterations when rendering progressively,
| these pixels stay darker than the rest. This is just how the
| algorithm works. You could try to apply a denoiser, but then
| you're not using the computational power to shoot more rays and
| you're replacing noise with bias.
| whoisthisguy wrote:
| I used Cinema 4D for years and a few months ago I gave a try to
| Blender. I have to say I was extremely impressed. I did some
| digging and it turns out Blender has an amazing product focused
| management thats main goal is to serve the users. Extremely well
| executed product management.
| monkmartinez wrote:
| Awesome!!! Those initial test results are darn impressive. Good
| to see they are working directly with Intel, AMD and Nvidia.
| dogma1138 wrote:
| For GPU rendering anything but NVIDIA wasn't even a second
| class citizen on Cycles for a long long time.
|
| Cycles X will likely be OptiX only and then OptiX first for
| quite a while until a true cross vendor cross platform stack
| appears.
| zlsa wrote:
| In the linked article, benchmarks are shown for CUDA as well.
| Of course that's also nVidia-only like OptiX.
|
| And antecdotally, OptiX is around 1.5-3x faster than CUDA
| with Cycles rendering.
| ravenstine wrote:
| I've kept an eye on Blender for the last 15 years and tried it
| again recently after having almost exclusively used Maya. It's
| continually improved in just about every way, is relatively easy
| to use with just a trackpad, and it performs really well.
|
| In contrast, Maya is has more features overall but is... a piece
| of shit in many ways. It doesn't matter what hardware I've used;
| it's a rule that Maya has to crash randomly when doing basic
| things. I used to be able to just _open the Hypershade_ , but
| with Maya 2020 merely opening it causes the entire application to
| crash.
|
| So I've decided to ditch it for Blender. I'm not doing character
| animation anymore, but I still enjoy modeling and rigging some
| things I want to conceptualize in 3D space, as well as create 3D
| printables, and Blender is absolutely up to the task.
|
| It kind of baffles me how little interest the motion picture and
| television industries have had in Blender. Big studios are still
| using Maya, which I _know_ also crashes for them and has
| performance issues. They could pour all their money into
| improving Blender and eventually not have to pay Autodesk anymore
| for licenses for poorly managed software that seems to rarely
| receive bug fixes.
| gmueckl wrote:
| Maya was an amazing piece of software once. It is falling
| behind only because Autodesk seems to be content to just let it
| slowly rot.
|
| The funny thing is that there are litanies of complaints about
| many core Autodesk products that echo the same chorus: the
| software is poorly maintained, bugfixes are promised "for the
| next released" (paid upgrade, of course) and yet, they never
| appear. Customer feature requests are completely ignored and
| each release feels like it's just a version number bump with a
| few token changes here and there so that sales can act as if
| they created a meaningful new release.
| raverbashing wrote:
| Well the cash cow keeps making them money and the Studios are
| happy to keep giving them money so why bother
|
| It's the same with Sports games, "corporate software" etc etc
| mroche wrote:
| Some of us admins in the field like to joke that Autodesk
| isn't a software vendor, they are a licensing company. And to
| be honest some of their changes with regards to Named User
| Licensing is going to be a PITA for many studios.
|
| I've gotten the chance to have a few conversations with some
| on the Maya team before, and they are great people. But they
| are fairly hamstrung by a company focused on sales and growth
| than development, one where M&E is less than 10% of their
| company revenue[0] (those numbers, which are an increase in
| revenue, can likely be attributed to the forcing of
| subscriptions), and having to cover a lot of ground re-
| architecting an application with a ton of technical and
| legacy debt. The historical idea of Maya being a Fraken-app
| exists for a reason.
|
| [0] https://investors.autodesk.com/static-
| files/749abc95-16be-4c...
| gmueckl wrote:
| Media & Entertainment being a tiny part of their revenue
| fits with the general wisdom that the market for general
| purpose 3D software is virtually non-existent. The software
| is costly to build and maintain and combined with a small
| customer base and thus high licencing prices, this is a
| killer.
| packetslave wrote:
| I mean, ultimately Autodesk doesn't give a damn about any of
| their other products as long as the AutoCAD money firehose
| continues.
|
| Maya continues to be the industry leader because VFX studios
| have spent 20 years integrating it with their pipelines.
| Blender could beat Maya feature for feature, and places like
| ILM and Weta _still_ won 't adopt it because of the effort
| required to fit it into their pipelines.
| qwertox wrote:
| I learned Maya on Irix, then purchased a License for Plug In
| development on Windows around 2004, which was pre-Python
| support. I really got to knew the DAG very well, as well as
| rendering custom helper tools in the viewport. It was extremely
| flexible to extend.
|
| I've also kept an eye on Blender since then, and no other piece
| of OSS causes me so much joy to see the improvements it makes
| version after version, specially because they are usually
| linked to small movies which demonstrate the capabilities.
|
| But the few times I've taken a look at the Python SDK, I've
| felt a bit turned off. It somehow felt a bit like Cinema4D,
| where you had this huge API to code against, but never ended up
| with small modules (DAG nodes) which were pretty much stand-
| alone utilities which you could then connect to anything Maya
| had to offer.
|
| I've seen that Blender lately has something which feels a bit
| similar, but it appears to be limited to shading pipelines
| (Shader Nodes).
|
| There are no such transform, group, deformer nodes and stuff
| like that which allows you to manipulate geometry, correct?
|
| I mean, in Maya I'd build a simple data node (in C++) which had
| an input, and I'd route the xyz of an object to the xzy-input
| of my data node, and then apply particle physics to that object
| and hit play, and the data node would then obtain a "data
| stream" in its xyz-input representing the object's position, as
| a very trivial example. Even vertices could be "streamed" into
| such data nodes. How would I do such a thing in Blender (with
| Python)?
| kroltan wrote:
| In addition to Geometry Nodes [0], and the "Everything Nodes"
| initiative [1], you might be interested in Sverchok [2] too,
| which implements this kind of graph-based
| parametric/procedural modeling technique.
|
| [0]: https://docs.blender.org/manual/en/latest/modeling/geome
| try_...
|
| [1]:
| https://wiki.blender.org/wiki/Source/Nodes/EverythingNodes
|
| [2]: http://nortikin.github.io/sverchok/
| haldean wrote:
| There's Geometry Nodes now which let you write smaller
| procedurals that you can combine together the way you're
| describing: https://docs.blender.org/manual/en/latest/modelin
| g/geometry_...
|
| They're extremely new (2.92 I think) so the framework is
| there but there aren't many nodes yet; 2.93 introduced a
| whole bunch of new nodes though.
| qwertox wrote:
| Excellent! The fact that there's something as basic as the
| Boolean Math node [1] kind of shows that this is something
| evolving into that direction. I will definitely look at it
| and search for the C-code on GitHub. Thanks.
|
| [1] https://docs.blender.org/manual/en/latest/modeling/geom
| etry_...
|
| Edit: Hmm, it appears to not have a C++ API.
| weinzierl wrote:
| > is relatively easy to use with just a trackpad
|
| The last time I tried Blender - which admittedly is a while -
| it was practically unusable with a trackpad. Has this changed?
| wlesieutre wrote:
| One major change is that it now defaults to select with left
| click, which should help things.
|
| There's also an official Pie Menus add-on that lets you fit
| more controls in a smaller laptop keyboard. Numpad is the
| normal way to switch between view directions, but having them
| in a radial menu keeps it reasonably usable.
|
| Lack of middle-mouse drag could be awkward and I don't know
| the solution off the top of my head, but I imagine there's
| something. You need to have both pan and zoom, I'd guess one
| is via two-finger scrolling and the other adds a modifier
| key?
| DonHopkins wrote:
| Pie menus are actually build into Blender now, but there's
| also a great Pie Menu Editor add-on that lets you easily
| build you own pie menus and other user interface widgets
| without coding in Python! Which is very important for
| making efficient custom workflows.
|
| https://blendermarket.com/products/pie-menu-editor
|
| Alias (and now Autodesk) has been abusing the patent system
| and spreading FUD about marking/pie/radial menus being
| patented for decades, which inhibited 3dsmax and Blender
| from supporting them for many years. But now Blender has
| excellent support for pie menus, and they're not encumbered
| by patents.
|
| Autodesk Advertisement About "Patented Marking Menus":
|
| https://miro.medium.com/max/534/1*3C79dFnlhN__OJ3XmEjN9A.pn
| g
|
| http://images.autodesk.com/adsk/files/aliasdesign10_detail_
| b...
|
| Pie Menu FUD and Misconceptions: Dispelling the fear,
| uncertainty, doubt and misconceptions about pie menus.
|
| https://donhopkins.medium.com/pie-menu-fud-and-
| misconception...
|
| >The Alias Marking Menu Patent Discouraged the Open Source
| Blender Community from Using Pie Menus for Decades
|
| >Here is another example that of how that long term
| marketing FUD succeeded in holding back progress: the
| Blender community was discussing when the marking menu
| patent would expire, in anticipation of when they might
| finally be able to use marking menus in blender (even
| though it has always been fine to use pie menus).
|
| >As the following discussion shows, there is a lot of
| purposefully sewn confusion and misunderstanding about the
| difference between marking menus and pie menus, and what
| exactly is patented, because of the inconsistent and
| inaccurate definitions and mistakes in the papers and
| patents and Alias's marketing FUD:
|
| https://blenderartists.org/t/when-will-marking-menu-
| patent-e...
|
| >"Hi. In a recently closed topic regarding pie menus,
| LiquidApe said that marking menus are a patent of Autodesk,
| a patent that would expire shortly. The question is: When ?
| When could marking menus be usable in Blender ? I couldn't
| find any info on internet, mabie some of you know."
| wlesieutre wrote:
| Even better!
| ravenstine wrote:
| Try using Maya or Cinema 4D with just a trackpad and you'll
| realize how well Blender works with a trackpad. ;)
|
| With Blender, it's not only a matter of learning the key
| combos, but it even has on-screen controls by default so you
| can at least use that. Maya _used_ to have something similar,
| but they pretty much got rid of it. It 's possible to
| configure Maya to make it easier to use with a trackpad, but
| the configuration for doing so is horribly obtuse and messes
| with mouse usage.
| blensor wrote:
| I admit I am a bit of a masochist in that area but I am
| almost exclusively using blender on my laptop for many years
| and once you get used to it and have setup your keys
| correctly, it works
| rideontime wrote:
| It's surprisingly good on a Mac trackpad, with support for
| lots of multi-touch gestures. Can't speak for other OSes.
| 127 wrote:
| Yes, Blender is an amazing project and great 3D production
| software for being free. However there are many issues that
| remain unresolved after years. Viewport performance being one
| of them. There seems to be at least to an extent a mode of
| development where fun new things get done but old, boring, more
| critical issues will not.
|
| I give all credit to Blender developers for doing the old,
| boring and important things. It's just very frustrating waiting
| for years and realizing that what was the vision a couple of
| years ago, very few things actually got done.
| mattnewton wrote:
| Presumably this happens because it's mostly volunteer labour
| right? Hiring a person to solve those boring old but
| important-to-your-business issues seems like it could pay off
| at a certain number of maya licenses.
|
| My guess is it mostly doesn't happen because these shops
| aren't in the software business and don't want to be, so
| don't know how to value engineers and don't want to spend
| money on engineering they aren't sure will pay off in this
| fiscal year.
| edflsafoiewq wrote:
| Blender is mostly developed by paid devs I think.
| rguetzkow wrote:
| I think there are quite a lot more developers
| contributing to the project than those employed by the
| Foundation or supported by developer grants [0]. However,
| the complex changes on the roadmap of Blender's
| development are planned and implemented by the core team.
|
| [0]: https://www.blender.org/about/credits/
| mkaic wrote:
| Viewport performance is one of the several major improvements
| demoed in the linked video by Brecht!
| packetslave wrote:
| A friend of mine in the industry who is now switching from
| Maya to Blender for concept art once said: "yeah, Blender is
| free... if you don't count the $200 in add-ons you need to
| buy to get anything done."
|
| I wonder what percentage of Blender enthusiasts DON'T have
| Boxcutter and HardOps installed at a minimum.
| jpm48 wrote:
| I think one of the main issues for Big studios is the whole
| pipeline is based around Maya / Houdini and it is easy to get
| artists who know these tools. It's hard to switch and takes
| time (see how many studios are still using Python 2.x as a
| switch to 3 will break so much). I know a lot of people are
| beginning to look at blender (mainly due to cost and the new
| licensing models from Autodesk). It is really expensive for
| studios to use now.
| dagmx wrote:
| Blender has a lot of things lacking however:
|
| * It too is crash happy just in different ways. However Maya
| scales better with large scenes than Blender does and that's
| key
|
| * Blenders licensing is a deterrent. Very few people want to
| deal with GPL.
|
| * Blender is not good for extensibility if you're looking for
| performance. The API is unstable and exposed only via Python.
| Studios need to extend the DCCs and Blender doesn't allow for
| it in the way they need unless they fork the whole app.
|
| *Blender has no professional support contract. This is very
| important for studios.
|
| I think Blender is awesome, but a lot of the stuff that makes
| it appeal to freelancers doesn't appeal to big studios. In some
| cases like the licensing, it pushes them away.
| semi-extrinsic wrote:
| Just as a counterpoint: in computational fluid dynamics there
| are many large commercial companies that use GPL softwares,
| and there are also commercial companies that offer paid
| support contracts for those GPL tools. Once it catches on in
| the community that these tools are good quality, there is no
| legal risk, and there is good support if you want to pay for
| that, they tend to spread rapidly.
| dagmx wrote:
| I think what you're saying is very much in line with my
| initial comment, if we skip out on extensibility for a
| second.
|
| If the Blender foundation offered paid support, such that
| studios used it like a black box (e.g like Maya etc), then
| the GPL part doesn't matter. They can get someone else to
| take on the burden and supply them with builds.
|
| Blender however doesn't offer that and I think it's a
| missed opportunity.
|
| However even if that were the case, extensibility is
| important. And unfortunately, blender doesn't have any API
| other than Python, and its API is GPL too. Studios need a C
| like API for performance reasons, and using the API
| shouldn't affect the licensing of their own code.
| thomastjeffery wrote:
| > Blenders licensing is a deterrent. Very few people want to
| deal with GPL.
|
| I see this claim taken seriously all over the place, and I
| just don't get it. How in the world is the GPL _actually_ an
| issue?
|
| The GPL does not apply to anything _made with_ Blender; only
| changes _made to_ Blender. You can very trivially use Blender
| without ever dealing with the GPL.
|
| Do studios really think they need to make changes/extensions
| to Blender itself, _then keep those changes totally private
| and proprietary_? How absurd!
|
| I just can't for the life of me think of a scenario where the
| GPL would actually inconvenience a studio. The only potential
| problems I can imagine are beaurocratic FUD like having a
| legal team arbitrarily demand every tiny piece of work be
| owned by the studio. What a silly reason not to use better
| tools.
| berkut wrote:
| When you write plugins (which VFX studios write a lot of
| for various DCCs like Maya, Nuke, Katana, Houdini) for GPL
| software, are the plugins then derived works? Does
| Blender's License have an opt-out clause for that?
|
| Sometimes (but not often) these plugins do need to be
| shared with other studios (or even the vendor - Netflix is
| starting to get fairly aggressive in asking for copies of
| the source work, but that doesn't really work well with
| every studio having a custom pipeline and different ways of
| doing rigging / deforming), but it looks like it's going
| that way. In this scenario, is "sharing" "distributing"
| from the license point-of-view?
|
| Large VFX/Animation studios are not going to open source
| critical plugins that given them potential edges. They want
| them to be totally private and their IP.
|
| The large studios have a lot of research / IP stuff going
| on as well, they are basically tech houses (hundreds of
| software devs), and they really care about IP (both
| software and the client's material).
| dagmx wrote:
| It's not absurd that corporate entities would make changes
| to their software without a desire to release those changes
| as code. It has serious implications on patents etc...
|
| If Blender had a stable C API that was dual licensed, you'd
| see a lot more studio uptake IMHO. Heck, even libc is dual
| licensed.
|
| This all comes down to the GPL not being well received by
| most tech corporations. People can argue whether that's got
| merit or not. However it's a long standing fact that tech
| companies do not like having dependencies on GPL code that
| can "infect" their code base. Entertainment studios are the
| same. They're largely tech companies at their core that
| create art.
| berkut wrote:
| This.
|
| Blender has some rather embarrassing performance choke-points
| even doing relatively simple things in some cases, that
| software like Maya and Houdini don't have to the same degree.
|
| GPL code (even if you're not distributing anything) is more
| of a problem than people would think, especially for places
| working on very strongly defended IP content (Marvel), where
| the content owners _need_ to have guarantees that the
| software used is fully-licensed (there have been quite a few
| incidents in the industry where unlicensed commercial
| software was used, which causes surprising issues, like films
| being delayed), and similarly they need to know the software
| licenses for non-commercial software used doesn 't have
| "surprises" in (some software has weird additions to
| licenses, like "must provide credits", and even the artists /
| developers working on the show for the studio don't
| necessarily get that).
|
| Extensibility is really the key thing: you wouldn't believe
| how much custom code is written for glue wrapping around
| stuff for integration - still mostly Python2, although 3's on
| the way for the industry, but the fact Blender only supported
| Python3 when the industry as a whole was still happy with
| Python2 (they don't really care about unicode, they would
| have loved the GIL to be removed though) meant it was a non-
| starter. Similarly, custom plugins (in C++ for performance)
| are required in huge numbers for various different things,
| modifiers, deformers, proxy drawing code, etc, etc, and
| Blender doesn't expose anything like that.
|
| Again, support: Autodesk are far from perfect, but they will
| fix critical bugs for key customers when they insist - i.e.
| there aren't work-arounds (often within a week).
| actinium226 wrote:
| > * Blenders licensing is a deterrent. Very few people want
| to deal with GPL.
|
| Why would a studio care about this? A tech firm would
| certainly care, but the entertainment industry? They probably
| don't know what GPL is and would probably just associate it
| with "free"
| MattGaiser wrote:
| GPL may as well mean radioactive as far as legal is
| concerned.
|
| A friend worked at a company where they banned GIMP as they
| feared that editing logos and other trademarks in it could
| invalidate them.
|
| Even working for a tech company, I don't think I would
| suggest using anything GPL as it would cause a fuss.
| ziftface wrote:
| I'm not a lawyer, but I'm pretty certain that's not how
| the GPL works. It has no effect on the content you create
| using the tool. It places restrictions on redistribution
| of the code itself. I don't think there are any limits on
| what you do with gimp or blender, unless you are
| modifying its code and redistributing it.
| dagmx wrote:
| Yes the GPL doesn't apply to work created by GPL
| software. I've heard people in companies be worried about
| it though because they misunderstand "using GPL
| libraries" as applying to work created as a product of
| them, rather than strictly software.
| rguetzkow wrote:
| The Blender Foundation is quite upfront about this though
| to prevent misunderstandings. It's directly addressed on
| the page that explains the license:
| https://www.blender.org/about/license/
| dagmx wrote:
| The case in point here though was GIMP not Blender. I'm
| not sure whether they provide or provided such
| clarification.
| rguetzkow wrote:
| They do in their FAQ:
| https://www.gimp.org/docs/userfaq.html#can-i-use-gimp-
| commer...
| crazygringo wrote:
| That is correct, but there are plenty of lawyers who
| interpret things incredibly overly-conservatively to save
| their own ass, just in case.
|
| If you're a senior enough manager and have a legitimate
| business reason then you can often push back enough and
| get them to give in, but it's really a question of
| whether it's worth your time and effort internally.
| jandrese wrote:
| There are definitely management types that see "free"
| software as "I can't yell at the vendor if something goes
| wrong." I've seen this many times in government contracts.
| It's a CYA move IMHO. Even if the vendor is never going to
| fix the bugs you find, you can at least blame them for not
| delivering on time.
|
| Of course it's even more silly when you consider that
| you're never going to be making patches to Maya, so in
| theory nothing is lost on the Blender side here.
| dagmx wrote:
| Maya has support licenses (as do most commercial DCCs).
| Studios can get Autodesk to patch Maya for you and give
| you custom builds.
| dagmx wrote:
| Studios are very much tech firms themselves.
|
| Quite a few have released commercial software, share
| proprietary software with partner/vendor companies , or
| contribute to OSS.
|
| As with any tech company, the GPL is a very unwelcome
| license for fear of how far reaching it can be.
| mroche wrote:
| I can assure you that legal teams in studios are just as
| aware as those in the tech field, even with the (for the
| most part) distinct lack of apparent software distribution.
|
| Even if it's just for internal consumption, legal likes to
| know what's going on and where it might impact them later.
|
| However, the GPL and other copyleft software will not for
| the most part have much of an effect on studios unless they
| sharing some of their IP they've created with the broader
| community, partners, and/or proprietary software vendors.
| packetslave wrote:
| Studios write a LOT of custom code for their pipeline and
| tools. If you were to go to ILM or Dreamworks or WDAS and
| watch someone use Maya there, it would look COMPLETELY
| different from what you see at home.
|
| Given that, I'm not surprised that the (not-always-
| technical) lawyers are worried about GPL.
| bredren wrote:
| Thanks for this feedback. Maya has been around forever. I think
| I had the initial release crash on me when in the late 90s. I
| figured it was the warez back then!
|
| Would you mind sharing what kind of character work you've done
| previously (hobby or pro) and what types of topics or projects
| drive you to use Blender for conceptualization?
| ravenstine wrote:
| Probably not because it was warez. I know people who work
| with Maya in productions; everybody knows that Maya is crash
| prone to varying extents. It's the least reliable software
| I've ever used. It does a TON, and it's otherwise pretty
| awesome, but it's embarrassingly buggy.
|
| I never really got to work with it in a professional space,
| but before software development I wanted to do character
| animation and went to school for it. Outside of assignments,
| I did a bunch of hobby projects both with just animation and
| sculpting. I was particularly interested in mixing CGI with
| live action, and there were some things I did with modeling
| and rigging things like monsters, filming footage, resolving
| camera motion, and compositing rendered animation into the
| video. Was both a lot of fun and horribly difficult. These
| days I it's much easier since software for resolving camera
| motion has improved by orders of magnitude.
|
| There was a studio I worked at briefly, but it was a pretty
| crappy deal and I decided to just ditch that field for
| software development, which I am much better at anyway.
| bredren wrote:
| :) It was hard to tell what was what back then.
|
| Thanks for sharing those notes on your character animation
| background.
|
| I'm curious what drove you to be interested in mixing CGI /
| live action. Jurassic Park, perhaps?
|
| When I was a kid Roger Rabbit and Cool World were amazing
| to me. JP's CGI seemed different, as though the dinosaurs
| were real.
| ravenstine wrote:
| Oh, I also didn't catch this:
|
| > what types of topics or projects drive you to use
| Blender for conceptualization?
|
| So I often have hobby projects (that I sometimes
| complete, heh) where I would rather sketch it out in
| Blender so I could more easily figure out what it is I
| want to build. Sure, I could be using something like
| Solidworks, but I've just never felt like I needed a full
| on CAD suite to do what I need. The process helps me
| design physical objects and decide what parts I'll need
| to either buy or 3D print.
|
| One such example is a 16mm film scanner I've been meaning
| to build. I have a 16mm projector and collect 16mm films,
| and some films you can find on eBay are kind of obscure.
| So I thought it would be fun to build something to scan
| them since it would use my programming talent and involve
| controlling stepper motors.
|
| That was actually where I gave up on Maya completely. I
| had used Blender for some things already so the
| transition was pretty easy, but I have more experience in
| Maya overall. After having it crash on something _basic_
| , not even potentially weird operations like booleans
| (which _every_ other 3D software package gets right), I
| decided to abandon Maya entirely and hopefully I won 't
| ever have to look back.
| ravenstine wrote:
| It was The Incredibles. That and my father was and still
| is an animator. But The Incredibles really got me
| interested because it was both pretty advanced for its
| time and had what I still consider to be a more mature
| storyline than even most animated films today. I
| definitely know what you mean about Roger Rabbit!
| monkmartinez wrote:
| Just an observation and a point of discussion regarding the big
| studios. Disclaimer, I am not in this space professionally, but
| I listen to a LOT of podcasts about VR/AR which spills into all
| of these topics.
|
| Do you see a push away from Maya and 3DS max for a more
| platform agnostic modeling environment? Blender seems to be
| mentioned all over the place for beginners. From what I am
| hearing on podcasts, Unreal Game engine is making a big push
| into film/animation production in addition to its impressive
| game credits. As long as you can export an FBX file UE4/5
| should be a great pipeline, or do I have it wrong?
| gmueckl wrote:
| The problem with UE4 in film/animation is about the the place
| it should occupy in the pipeline. Being a game engine at its
| core, it's fundamentally designed to ingest models and render
| images. So its natural place is at the end of the pipeline.
| There's no really good roundtrip capabilties that let you
| e.g. export a scene that was created in UE for use in other
| tools. So despite the interactivity that would let you e.g.
| block out a scene with awesome real time feedback, there's no
| good way to get the data out into a different animation or
| lighting tool for final touchups before it goes to an offline
| renderer. This is why some big animiation studios have
| invested a lot of effort into in-house realtime preview
| renderers that attach to their tool pipelines with less
| friction.
| ravenstine wrote:
| That's an excellent point about why they would rather write
| their own in-house software. Of course they then get
| saddled with having to support all of that software and may
| struggle to do so, which is another problem in itself.
| ravenstine wrote:
| I'm not in the field myself, though animation was my original
| career and I know people who work in feature animation.
|
| To answer your question, the field has been _sloooowly_
| diversifying in some ways, as you say with Unreal
| (particularly since Unreal 's engine is fast and good for
| real-time previews), but I don't see a huge push for moving
| away from does-it-all packages like Maya or 3DS Max. The
| economic incentive isn't there. Studios have figured out how
| to make their money and are comfortable with the pipelines
| that they already have. This isn't to say their pipelines are
| _good_. In fact, many of you would be shocked at just how bad
| most animation pipelines are at big studios. Not only are
| they way too vendor-locked (as is kind of the case with
| Maya), but they don 't want to pay an adequate salary for
| qualified software engineers who can build better pipelines
| and write more software that's agnostic. Of course, I'm
| making sweeping generalizations, but this is the kind of
| story I've heard more often than not. Pixar is known for
| having good practices and they write (and sell) their own
| software, but I don't closely know anyone who has worked
| there.
|
| It's going to take a decline in the field of animation before
| studios realize that they're basically stuck in 2006 in terms
| of how their artists are working to make their content. I
| won't mention them here, but people at certain major studios
| have been trying to get things like Unreal for 10+ years and
| never get approval to receive licenses for it and they never
| do because higher ups don't believe they'd see a monetary
| return on investment. Their content is so profitable that the
| people in charge don't really give a fuck.
|
| In case I didn't make it clear, I'm pretty much an outsider
| at this point, so I'm sure there may be some more relevant
| viewpoints here that would contradict mine. I don't intend to
| be authoritative.
| lattalayta wrote:
| In my opinion, most of the 3D software and renderers are
| starting to align in their workflows and set up. If you've
| spent enough time in a 3D package and have your
| fundamentals down, then a reasonably experienced 3D artist
| could make something look good in Maya, Blender, Cinema 4D,
| UE4, 3ds Max, Modo, or slightly more specialized programs
| like Katana, Mari, Nuke, etc. Most of the "learning curve"
| is just finding out what a particular program calls one
| tool or another. I think this video starts to illustrate
| what I mean
|
| https://www.youtube.com/watch?v=VkvRBvKHFek
|
| Also, at studios, you tend to hear about the "main"
| pipeline where the majority of the work flows through.
| There are often secondary, smaller pipelines where they
| evaluate new tools and workflows before committing to
| entire rewrites. I would agree that small to medium sized
| studios don't have the resources or luxury to do as much
| exploration
| ethbr0 wrote:
| > _Their content is so profitable that the people in charge
| don 't really give a fuck._
|
| This is usually a general technology smell. Consistent,
| profitable revenue is the technological equivalent of the
| resource curse [0].
|
| I haven't figured out if it's because people never get
| fired (thus new ideas are extremely slow to penetrate and
| propagate) or because management can afford to be extremely
| conservative (no pressure, resistance to change).
|
| Put the most charitably, it's because there's no need to be
| more efficient, and stability & consistency is more
| valuable than improvement.
|
| [0] https://en.m.wikipedia.org/wiki/Resource_curse
| emkee wrote:
| Watching Blender become more and more prominent over the last
| several years has been extremely satisfying. This looks like
| another great step.
| dragontamer wrote:
| Does anyone know about good books that discuss the various design
| decisions behind the "kernel graph"?
| (https://code.blender.org/wp-content/uploads/2021/04/cycles_x...)
|
| I mean, I recognize that its the "graphics pipeline", but there's
| all sorts of performance discussion points. You want the data to
| be in a particular form as it traverses the graph. The various
| bits of the graph want to be "pipelinable", and parallelized if
| possible (possibly executing on a 'Remote' GPU). The data may-or-
| may not be local to a certain location. (Ex: data in DDR4 will
| need to be transferred to GPU, and back. Or if you're in a
| render-farm situation, you may need to TCP-send the data to the
| remote computer before that computer can move forward with its
| rendering).
|
| And of course: all of those need to be balanced out with the
| featureset of the underlying program. Anyone can make a fast
| "sphere-only" renderer/raytracer, but Blender supports many
| different types of meshes, NURBS, and other features, which is
| probably the bulk of the complexity.
|
| -----------
|
| The depreciation of the OpenCL kernels is a bit sad, but
| understandable to anyone who has actually worked with OpenCL vs
| CUDA vs ROCm. The OpenCL kernels in Blender are particularly
| weirdly coded, so throwing them away might be the best option.
| birktj wrote:
| > Deprecation
|
| > OpenCL rendering kernels. The combination of the limited Cycles
| split kernel implementation, driver bugs, and stalled OpenCL
| standard has made maintenance too difficult.
|
| I am not really up to date on the GPGPU world, but is OpenCL in
| such a bad shape that it is not really usable? If so that is very
| sad. Are there any alternative open hardware agnostic GPGPU apis
| or has CUDA eaten the entire market?
| raphlinus wrote:
| My perspective is that OpenCL is indeed in that bad shape,
| though it does have defenders. Both AMD (ROCm) and Intel
| (oneAPI) have ways to run workloads originally written to run
| on CUDA, but they're nowhere near the level of polish as CUDA.
|
| I believe an open stack can and will emerge, but it will take
| time and effort on all levels of the stack. It's possible to do
| pretty amazing things with Vulkan compute shaders, but the
| programming model is different than CUDA (it's not single-
| source), and the tooling support is not quite there.
|
| In time, I am hopeful that WebGPU will gather more momentum,
| and be officially supported even in places where Vulkan
| requires janky adapter layers. But in its current form, it's
| very immature and far from being usable for real workloads.
| dogma1138 wrote:
| ROCm is a total mess, and is Linux only.
|
| OneAPI is in a rather good state considering it's barely a
| release candidate now I'll put my money on Blender support
| Intel GPUs sooner than AMD ones with Cycles X unless AMD will
| adopt OneAPI.
| jsheard wrote:
| ROCm doesn't even run on every AMD card, it only supports a
| subset of their architectures skewed towards the HPC market
|
| The current and previous generations of consumer AMD cards
| just don't work with ROCm and there's been no indication
| they ever will
| brundolf wrote:
| Oh man, I am pumped about the viewport improvements. Whenever I'm
| working on a scene, tweaking lighting or shaders is really
| arduous because after every tiny adjustment I have to sit and
| wait at least a few seconds to really see what effect it had.
| These previews look amazing.
| valine wrote:
| Have you tried using Eevee for shader adjustments? A pretty
| common workflow is get your lighting setup working with Eevee
| and then switch to Cycles for the final render.
| brundolf wrote:
| Certain shader nodes only work in Cycles. In particular I use
| the Bevel node a lot for an "edges" effect: https://docs.blen
| der.org/manual/en/latest/render/shader_node...
|
| You can get the difference between the surface normal and the
| bevel normal and use that as a "sharpness" value to mask
| things like wear on the corners of objects
| knolan wrote:
| One other suggestion is to use a render border.
|
| https://docs.blender.org/manual/en/2.79/editors/3dview/navi
| g...
| capableweb wrote:
| > A pretty common workflow is get your lighting setup working
|
| Don't think that's common at all because that won't always
| work well. The difference between Cycles and Eevee is the
| lightning, materials, rasterization (compared to raytracing
| that Cycles does) and such.
| brundolf wrote:
| The GP is correct in many cases. Part of the reason Eevee
| was created was for this exact purpose. You can't preview
| certain shader nodes (though you can preview most of them),
| and you can't preview raycast-only effects like indirect
| lighting (unless you bake it) and certain volumetric
| effects. But you can preview your geometry and direct
| lighting and physically-based materials well enough to get
| an idea of how things will look, and then you can make a
| final pass where you preview the actual Cycles output.
|
| If you're fixing your UVs, or adjusting the depth of a bump
| effect, or arranging a scene to see how objects' colors
| balance with each other, or tweaking the metal-ness of a
| material, Eevee works great as a preview even if your final
| render will be in Cycles. Eevee is particularly useful when
| working on an isolated object (minimal indirect lighting),
| vs seeing how an entire scene gets lit.
| zlsa wrote:
| I've found that with complex shaders, it can be more performant
| to use CPU Cycles rendering because GPU rendering can have a
| substantial delay after changing parameters. In the same vein,
| Cycles is sometimes faster than Eevee, because the latter needs
| to recompile the shader after every change.
| brundolf wrote:
| Edit: I should clarify this only applies when
|
| 1) I'm using a Cycles-only shader node (which unfortunately I
| do a lot; see the thread below), or
|
| 2) I'm focused on lighting the full scene with all the
| indirection, or
|
| 3) I'm adjusting volumetric effects
|
| Otherwise Eevee is a great stand-in
___________________________________________________________________
(page generated 2021-04-23 23:00 UTC)