dahart

No difference, you’re right. I meant polynomial not geometric. :P

That’s quadratic, not exponential. 2^n != n^2

I’m sure exponential is what parent meant, but geometric (edit: polynomial) is what actually happens, not exponential. Code complexity increases linearly when it doesn’t interact with other features, and geometrically when it does. In the worst case, complexity increases as the square of lines of code. That is still very, very bad, but it’s not exponential.

Re: throughput vs latency - what is the implication for having a signed floor divide sprinkled in with other math? Is Robison likely to be the better choice unless I’m doing divide operations on long vectors/arrays of numbers?

If the goal is wide vector divides, what about GPU? How does this algorithm compare on GPU? Are GPU uses less likely to rely on and benefit from throughput behavior if the vector of divides is spread across all threads?

I don’t do image gen regularly… so I’d love more context. I can see some less good features in the images but I’m not fluent with what today’s generators would do. I agree with GP that it would be quite useful to know about the prompts & iteration effort. If generation times changed, they could be relevant & helpful.

> good luck predicting where I’m going to have my next cuppa.

Why are you assuming there isn’t someone else trying to hack you at the next cafe? Actual damage can happen one person at a time, and can occasionally lead to larger scale compromises. Randomizing your location isn’t going to reduce your risk. Now that everyone who’s paying attention knows they can MITM your Mac, you shouldn’t trust any network.

Unfortunately, the goal with OpengGL is not to teach graphics and rendering concepts. Same goes for DirectX, Vulkan, WebGL, etc. These APIs are being designed primarily for performance, not for ease of learning. For teaching and learning, it’s a great idea to start with rasterization & ray tracing in software first! That can teach you the graphics concepts first, and also provide good motivation to learn a graphics API if you want it to go faster.

Vulkan, OpenGL and DirectX make GPU programming more difficult than it has to be for multiple reasons, some of which other people here have mentioned. They are also low level, focused on high performance, and are primarily designed and written for game engines. Making them easy to learn for newcomers is pretty low on the priority list. ShaderToy makes it easy by taking care of everything except the GLSL, you might like it. You can also try CUDA, which is generally a lot easier than Vulkan. For a really easy/fun time with CUDA, try Warp - it’s CUDA in Python.

Nope, they were just written in C. It was object oriented C, but without a C++ compiler. Do you know the story about the whole C++ toolset that was rolled out by R&D and promptly rejected by production? That happened before my time, but according to legend is what lead to PDI’s strict avoidance of C++… until a couple of years into the DWA merger. (Clearly there were some problems beyond C vs C++, but I don’t know the whole story.) Anyway, yeah I remember starting on the 64b transition, but left before that was finished.

Interesting, had never heard of Kono Express. It definitely looks a little ‘Unreal’, has video game vibes. The quality is pretty good at a glance, especially the environments and effects, but it doesn’t feel all the way there under scrutiny. This reminds me of all AI generated stuff (so far) - looks great from a distance but from up close you see glaring problems. The lipsync feels automated and robotic all the way through well past ep3, for example. Very little action in the whole series.

TBH I think it’s a big mistake to compare this to hand-animated Disney material. They are just very different things, and the debatable comparison will just cause people to focus on what’s wrong with Kono. If you think it’s good, just talk about the good qualities and share it. Also don’t forget the AI is trained on Disney material, and with heavy AI, it’s highly questionable whether you can credit one person for “cranking out stuff”.

What is the ink & paint comment about? The article doesn’t mention ink & paint…

Oh definitely - custom vs commercial. I remember the R&D team having to write a yearly report to justify the development expenditure, explain repeatedly why we were writing custom tools & renderer when these things were available off the shelf. I heard a few strong rants here and there about how the suits just didn’t understand. I remember the term “NextGen” being thrown around but I don’t remember if I lived through it or it was just getting started when I left (before S3). Jono I and tried for a while to stop having our shaders rewritten in C++ (without otherwise changing them nor adding any features). We eventually gave up and just kept building new things, but that was a fairly successful strategy to nudge the IP, tech, and support southward. Possibly the right strategy in retrospect, but felt a little rough at the time.

> The designers would fully texture out the inside of a dresser draw that will never be showing in the film. The idea was imagine how much attention to detail

Hehe, as an ex FX animator/TD, this sounds kinda funny to me, there’s likely more to the story. If they knew for sure the textures weren’t going to be shown, it’s a waste of time, not craftsmanship or attention to detail. But it’s plausible because often modeling & surfacing departments have to start work before the shots & camera are fully planned. And sometimes there are camera changes late in the production. It could be that someone’s shot that saw the inside of the dresser drawers got cut, that surfacing expected the drawers to be open in a shot, or that a scene inside the drawer was in storyboards but didn’t make it to layout, stuff like that happens a lot. But no productions are having artists work on stuff that they know will never be shown in the film.

“Better” is a loaded word. When you write your own renderer, you have a lot more control and a lot more support. Renderers at the time had not all converged on the same algorithms, so you could have a competitive advantage by writing a good one. PDI’s shader system was different than RenderMan’s and had some real advantages — compiled shaders, geometry & light shaders (not just materials), particles & particle shadowing, compositor integration, etc.. The renderer also needs to integrate into the pipeline deeply, so PDI’s renderer fits the PDI/DW pipeline better, whereas with RenderMan you have to try to mold the pipeline to fit the renderer in.

Hey I was on the PDI side as well, ahoy, nice to see you here! I had forgotten about Shark Tale using RenderMan, but I will say to the degree there was competition and to the degree that PDI won any pipeline battles, DWA eventually won the war. :P ;) There was plenty of cooperation as well, it just takes time for two companies to integrate, and plenty of people on both sides were quite attached to the cool tools they made. (I was certainly guilty!)

PDI’s toolset was pure magic for it’s time. When I joined, I was in heaven with how easy it was to make procedural animation, build new effects that crossed pipeline stages, render anything you could imagine… I wished I could share it with researchers and hobbyists.

Both companies each had their own renderer & rendering development team before the acquisition. And their own pipelines. A couple decades later, that’s still true.