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.
The Symbolics Lisp Machine S-Geometry 3D modeler from the mid 1980's was based on the winged-edge structure. It was the best polygonal modeler of its time, and the package lives on in philosophy as the Wings3D open source modeler.
"He can see far; further than in fact his strength allows him to travel. He conceives of brilliant ambitious projects requiring great resources, and he embarks on them only to run out of steam. It's not that he's lazy; its just that his resources are insufficient."
This speaks to me. As I get older, I am tempted to start curating a list of my "failed" (or abandoned) projects.
I have been fortunate enough to launch an open-source 3D graphics Lisp project late in life which has managed to keep my interest. Early on, I made a number of conscious decisions about how I would view this project and avoid some mistakes of my past.
- No comparing to existing 3D packages. It's evident that I can't compete with commercial packages with decades of programmer effort.
- No hunting for a "better" language (though this hasn't really been a problem). A goal of the project is to develop a system where I can bring the power of Common Lisp to bear on 3D graphics. In some ways this is a throwback of work I did developing 3D graphics on Symbolics Lisp Machines back at the MIT Media Lab [0]. Returning to my youth?
- Keep it simple. Or, does it need to be more complicated? Understandable code is a benefit, as is code you can (mostly) keep in your head. Avoid excessively clever code, which I have been guilty of in the past (macros, anyone?). Also (more controversially) avoid dependencies where possible; keep it in house.
- Build a community. Having others involved is the best way I have found for not running out of steam. My other projects have invariably been solo efforts. Now I am interested in creating something which will outlast me. Hence the decision to put the project on Github [1].
- This "thing" has value in and of itself, and doesn't need to be "better" than what is out there. By virtue of being different enough, it is a worthwhile project to bring into existence. The world probably doesn't need another browser-based JavaScript package.
- Keep the momentum going by working on whatever interests me at the time. Avoiding tedious development and yak shaving keeps me from losing motivation. I do realize the article touches on this as a weakness of the Lisp developer mindset, and I admit to not being motivated to build an industrial-strength system. E.g. my half-baked GUI built on top of raw OpenGL.
- Finally (have to stop sometime), don't overthink things. Enjoy the journey. I am enjoying enhancing the system while not fretting over who will use it or for what purpose. The journey is the destination.
I work in a slightly different way by always saving my code in emacs and loading it fresh each session (though I have gone a couple of weeks with a live image/session on my laptop). I am fortunate that my 3D system [0] compiles and loads in a few seconds.
I also use the REPL for quick tests, and evaluate new code by writing it in emacs and compiling it one function at a time (C-c C-c).
Finally, I keep files of tutorial/demo/test cases which work a bit like a notebook, allowing me to quickly verify that existing 3D scenes still work.
I think there is an opportunity to rethink a system for computer animation. Existing DCC packages are stuck in the late-80's mindset of animation consisting of interpolated values between keyframes. I wrote two such systems in that timeframe: Neo-Visuals and Softimage.
As far as I've seen, neither Unity nor Unreal have moved in this direction. Their "sequencer" solutions are IMHO unwieldy kludges that don't take advantage of new higher levels of abstraction for producing computer animation.
We have moved the artists up in part from animation to puppeteering (mocap). The next step is to move up to directing.
Allow the artist to interact with scene objects/characters as a director would. This requires what I used to refer to as "intelligent objects" back in the 80's. You would give directions and the object would figure out what it needed to do and how it would move.
So there would be a higher level of conversation with the 3D entities than "Set rotation keyframe."
Mocap requires a pretty significant amount of manual cleanup. The VFX industry is not a fan of Andy Serkis's bragging, to say the least. =P
I was extremely impressed with this motion matching presentation from GDC 2016. It blew folks away at the time. That said it hasn't really taken off everywhere AFAIK. Although it's definitely used in places (sports games!) https://www.gdcvault.com/play/1023280/Motion-Matching-and-Th...
I guess I like the idea of "directing". But in terms of pure practicality I'm very skeptical. What does the directing toolset look like assuming we don't have full blown AGI? That's tough. And I'm not super bullish on AI for this type of thing. Although I've been consistently surprised by ML capabilities over the last year. So in 3 years I'll probably say "oh yeah it was obvious that ML could do that..."
I see this as a long-term approach which will improve over time. Mocap can play a part, as can AI -- though I'm no expert in it, it's hard to argue with the results produced by tools such as Midjourney -- and other techniques.
The key point is tackling the animation "problem" from a new vantage point, as opposed to having an interface based on numerical interpolation as the final solution.
That makes sense in a video game sense; games like Fifa (or whatever it was called recently) have pushed dynamic animations forward by a lot, first by being able to transition seamlessly from one animation to the next, most recent one with volumetric caputure, so they can make 3d animated characters just from multi angle video footage.
But in that one, the player pushes a button and the character moves accordingly, picking natural movements and combining / merging them into something that looks pretty natural. I don't think that'll be useful in close-ups, but can be for e.g. crowds or wider angle shots.
The idea would be to cherry pick simpler cases, such as crowds and "background" actors. Hero shots and closeups would evolve over time as the techniques improved.
One advantage of authoring cinematics as opposed to games is the lack of a requirement for real-time interaction. The cinematic sequence can take a few seconds and analyze/plan accordingly.
These were both 3D systems running on SGI boxes, which allowed interactive editing of animation curves. Softimage was used for "Jurassic Park" among other films.
It lives on a Clozure Common Lisp, though there is no version for Apple M processors. Kind of a shame.