kaveh808

Yes, I would imagine you can easily render the movie in real time today.

There were stories about Aki, the main character, might become a virtual star. But I don't know how seriously this was considered.

If memory serves...

3D: Maya (starting with a beta version) Rendering: Pixar Renderman (prman) Compositing: Shake Hardware: SGI Octane workstations Renderfarm: Pentium 2 boxes

https://old.reddit.com/r/FinalFantasy/comments/1xgd2qy/ama_f...?

I led a team of a dozen developers to write software required to make the movie.

We were working with very early (beta) versions of Maya running on Silicon Graphics workstations. My team developed software for simulating hair and clothing, deformation and surface refinement tools, and anything else required to generate "photorealistic" humans.

As most things with my career, there were fortuitous coincidences. I was working on early hair and cloth simulation at a startup in Montreal and someone I briefly crossed paths with ended up at Square USA and recommended me to the company. The industry was very different 30 years ago: there were very few people working on things such as CG hair and cloth.

I am now teaching computer graphics at the University of Hawaii. Passing on what I know to the new generation.

It remains to be seen what the impact of AI will be on the industry and art form. I am currently creating a new course on AI and animation to be taught next year.

"The Spirits Within" was produced at Square USA's Honolulu studio. We were disbanded by the time "Advent Children" was made by a team in Japan.

The Honolulu studio produced FF:TSW and "Final Flight of the Osiris", a short for the "Animatrix" anthology.

The lack of commercial success of FF:TSW led to the Honolulu studio being closed down. The staff spread out through the CG industry and took with them the lessons from the project.

Right out of college, I wrote my first ray tracer in Fortran in the mid-80's at the Xerox Research Centre of Canada. I remember the setup being a VAX 11/750 with a RasterTech color monitor (512x512 if memory serves). [0]

My implementation was based on David Rogers' "Procedural Elements for Computer Graphics", one of only two texts available on 3D graphics, the other being Foley and VanDam.

I remember managing my own stack in a language which didn't support recursion. I learned a lot. Good times.

[0] https://medium.com/@kaveh808/8-summer-at-xerox-in-24-bit-col...

Basically, I launch my Slime/SBCL and do my development by editing and evaluating code in my Emacs buffers. This updates the running image and I can check the results interactively. I regularly save my buffers as one does.

This process can continue for days.

There are times when I need to relaunch my Slime/SBCL and start fresh. These are usually cases where I do some refactor that eliminates some functions, or when a bug causes crashes and I feel it would be cleaner to start fresh.

All pretty common sense.

I never save my Lisp image and relaunch it. Maybe I would if I was delivering binaries, but my project is open source.

I have always viewed the Emacs/Slime/CL development environment as being a more frictionless approach than the compile/link/execute approach of most other languages, but I get the impression there are people who evangelize "image-based coding" without having tried it out themselves.

The idea of not maintaining properly documented sources would terrify me.

As people point out, if you are not careful and execute arbitrary code in the REPL, your source and image can drift out of sync. When I was working on [1], I would go days without relaunching my image, but all the development was done by evaluating code in Emacs buffers and seeing the results right away. Occasionally, things got convoluted enough that I relaunched the process as a sanity check.

For me, the real benefit of iteratively modifying a live image lies in the sense of flow it engenders. I have not felt that sense in languages other than CL. I sometimes explain the feeling by saying than CL is the only language that I don't feel is fighting me.

[1] https://github.com/kaveh808/kons-9

I worked at that company: Visual Edge, in Montreal.

I wrote about this a while back. I'll assume the article is more authoritative.

https://medium.com/@kaveh808/6-object-oriented-ice-cream-fla...

I wrote a blog about some of my experiences at the then-new MIT Media Lab in 1985. Unlike the experience of the author, I was more of a lone late-night hacker (in the old sense of the word).

Thread starts here:

https://kaveh808.medium.com/from-arcmac-to-the-media-lab-229...

Right on.

The way I think of it, CL is the rare language that I don't feel is fighting me every step of the way.

I remember reading that at one point the NFL was Kodak's biggest client for 16mm film. Back when that was the format for recording the games.

Perhaps I'm viewing the past through rose-colored glasses, but I wish there were such efforts at innovation in the computer field today. Maybe the last attempt at doing something truly different was the Connection Machine.

I hope for the sake of my former colleagues at Weta that those transferred to Unity can simply be transferred back to Weta.

The point of production pipelines being bespoke (at least past a certain company size) is a relevant one. The main workhorses of large scale production (Maya, Houdini, Nuke, etc.) are extremely customizable and extensible. Over years (decades in the case of Weta) companies develop highly complex workflows and associated tools based on these applications.

That is why the Unity deal never really made sense to me. The idea that Weta's tools could somehow be packaged up and delivered as essentially shrink-wrapped consumer-level add-ons to Unity was a naive one at best. I'm not entirely surprised to see it fall apart.

Is there any movement towards a C/C++ API in Blender 4.0? I feel extensibility may be where it lags behind Maya and Houdini.

Very cool. I must check this out.

I implemented some L-system features in my 3D Common Lisp system: https://github.com/kaveh808/kons-9

kons-9: https://github.com/kaveh808/kons-9

Work in progress on an IDE for 3D graphics written in Common Lisp.

Cheesy trailers:

https://youtu.be/THMzaVDaZP8

https://youtu.be/i0CwhEDAXB0

https://youtu.be/liaLgaTOpYE

Yes. Though unfortunately CCL does not run on Apple's M chips.

"Vulkan represents a low-level way of talking to the GPU more or less on the GPU's terms. As opposed to OpenGL which is a way of talking to the GPU on boomer CAD programmers' terms."

Kind of like that description. I've been doing GL since before it was OpenGL.

In my Common Lisp 3D system [1], I've been happily using very simple immediate mode OpenGL calls, taking advantage of CAD-like features such as drawing wireframes of various thickness over shaded polygons. OpenGL provides specific Z-buffer API calls to facilitate such things.

Is there a simple way of doing such CAD-centric things in Vulkan?

[1] https://github.com/kaveh808/kons-9

Some basic Common Lisp videos showing Emacs/Slime in action:

https://www.youtube.com/playlist?list=PLTA6M4yZF0MzsMlNL0N67...

The killer feature of whatever game engine replaces Unity in developers' hearts and minds is going to be the platform delivery aspect.

Once you can press a button and get Win/Mac/Linux/Android/iOS/etc versions of your game built, you're in business.

All the higher-level features (3D, ray casting, etc) will be contributed by the community over time.

MCL was a delight to program in. Ran in 2MB on my PowerBook 170 and gave high-level support for GUI development.

It lives on a Clozure Common Lisp, though there is no version for Apple M processors. Kind of a shame.

His book "Colorvision" is a rich and wonderful book of design. I spent so many hours flipping through it.

In some small way I am revisiting the idea with https://github.com/kaveh808/kons-9

We'll see what comes of it.

I developed my first 3D graphics system on a Symbolics back in the mid-80's, before Symbolics released their S-Geometry package.

Though the software was powerful and made use of the extensibility provided by Lisp, it failed to gain much traction in the industry because the hardware was not suited to 3D graphics. Silicon Graphics (SGI) workstations took that market by the early 90's.