I know 3D graphics, but I realize there are folks out there who know a lot more than I do in their respective fields. And I hope to tap into that knowledge.
I went to the computer history museum on the weekend and took a pic of a symbolics machine for my workplaces slack that got a lot of love, I think there’s still some nerd points there :P
It's not entirely clear (and I think you even said that) where this is going. Tangentially, there is IMHO a great need for new FLOSS geometric kernel for CAD applications. The only option right now are OCCT: https://www.opencascade.com/open-cascade-technology/
which is really huge
CAD systems use trimmed NURBS which have a lot of challenges. I wonder how choice of language would help to address some of the complexity. Addressing this is definitely a project unto itself, while having much narrower scope than a new Blender.
I remember trimmed NURBS from back in the 80's, when the holy grail for 3D systems vendors was landing car companies as clients. It was not easy.
Later, at Square on the "Final Fantasy" movie, we were having trouble modeling our character models using NURBS due to continuity issues when more than four patches met at a corner. I resolved the issue by implementing a subdivision surface plugin for Maya. Overnight the workflow switched to polygons.
Would be great to have NURBS and other parametric representations as plugins in the system.
One of the most exciting things about this project will be seeing what gets developed on top of the system.
A truly new geometric kernel would be great, and it's been a dream of mine, but I have too many other things that need to be finished before I start writing one.
Usually when you talk about a geometric kernel in the past three decades, you're talking mainly about, but not exclusively about, a solid modeler.
A solid modeler generally consists of a trimmed curve and surface library with lots of topological reasoning, to be able to represent closed regions of space and manipulate them by adding holes and rounding features and offsets. The idea is to be able to represent and operate on just about any 3d shape imaginable. Solid modelers of recent years have had support for nurbs surfaces and polygonal subdivision surfaces, but also include support for conic sections, beziers and other implicit or parametric curves or surfaces. Many of them, like OpenCascade are arranged in a logical object oriented fashion which abstracts the complexity. They have to be general, featureful and fast for anybody to want to use them. It's a whole heck or a lot of math and geometric reasoning (and debugging) which makes them valuable (and huge), and although you might want to talk about a "new" kernel you would never just want to chuck something like OpenCascade and start over. OpenCascade, ACIS, Parasolid, SMLib and others encapsulate a huge corpus of knowledge no matter what language they are written in. I have taken criticism from other Lisp hackers for writing Lisp bindings to OpenCascade instead of "starting over" in Lisp, but these people really have no idea what they are talking about.
Interesting. Sounds like a non-trivial undertaking. Both writing an interface or starting a new design. Either way, I would be happy if our system develops along to the point that serious engineering packages would want to use it.
The colors in the demos reminds me of Wings3d, a 3d editor written in Erlang. It had quite a unique user interface to it, with modal bindings not unlike Vim. Are the color choices a coincidence?
I based the menu design on the Symbolics menus, and Wings3D is a descendant of S-Geometry in spirit.
I wanted a quick way of assigning some colors so I just made a rainbow color ramp. If you mean the red color for selection, then yes that was inspired by watching a Wings3D video.
You should start by building and shipping something even if it is minimal. Starting an open source project with a post calling to form a team and so on is an anti-pattern imo. Good OSS projects always should start with code from one or maybe two people that does something useful, and attract contributors from there. Just my 2c, good luck!
I agree with the GP that it's very difficult to get contributors if the project is not usable. Reading the post in reddit, it looks like just a call for help for an empty project.
But looking at the repo linked in the post https://github.com/kaveh808/kons-9 and the demo, it looks like you have something that is already working.
Also, what does this mean in the readme?
> If you're brave enough, change the pathnames in main.lisp and eval the buffer.
Another important thing to get users (and later contributor) is a complete idiot proof method to install the project and run the demo [1]. something like "git clone & make demo" or whatever is the correct syntax for that spell.
Yes I think you should spend some time cleaning up your PoC into a real, usable project. Write a nice readme, get it so anyone can run it quickly and easily, etc. In my most recent github project I released [1] I also used DALL-E to make a nice header to the README, which can also help make it feel like a solid thing to be worth checking out imo.
If memory is reachable the surviving pictures of old Lisp Machines had inside color line diagrams where the memory is. Should Common Lisp and Khronos Vulkan API control color threads in the kernel space and that memory persists throughout the lifetime of the hardware will that open the door to a different style of "learning machine"?
Usually it was by word of mouth, people learning of my work and contacting me for a software position. The landscape has changed a lot since those times.
I know 3D graphics, but I realize there are folks out there who know a lot more than I do in their respective fields. And I hope to tap into that knowledge.
It's going to take a team to do this project.