kaveh808

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.

Been working on particles and sprites recently. Decided to make another tongue in cheek trailer.

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.

https://www.youtube.com/watch?v=UNXEemZ_Ysk

"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.

[0] https://medium.com/@kaveh808/late-night-lisp-machine-hacking...

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

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.

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

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.

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.

I worked on Gazebo in its early days.

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."

I wrote up some recollections.

Neo-Visuals:

https://kaveh808.medium.com/10-17-000-polygons-should-be-eno...

Softimage:

https://kaveh808.medium.com/17-the-softimage-siggraph-sprint...

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.

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.