simple cad question

[gedw99]

I like the parametric and simulation aspects of SDF and was wondering if this code is cable of simple 3D that an Architect would do..

I am an architect , turned to the dark side of IT, and frankly am sick of the crappy CAD systems out there, and all the limitations and file format lockin. the AEC industry is completely nuts - pun intended. It's pretty simple but they make it fancy pants complex. You cant do forward engineering either...

How about this as a bare bones example ????

• site made up of 10 triangles to represent the basic undulations.
• house with walls, doors, windows, trusses, roof, etc. Glass will have to be just empty space, as there is no way this things can do transparency etc :)
• can make a sun shadow diagram with a light source, and see the shadows cast by the house onto the flat site. Can hook it up to some API that when given place on earth etc can put the sun in the right place for the classic sun shadow diagrams.
• can make plans, sections, elections, and output in some stupid simple format. Not that interested in DXF actually. Maybe Deck - https://github.com/ajstarks/decksh/blob/master/test.dsh, so from this DSL I can then output the RD to whatever final formats I like and have control over everything. again sick of being locked it :)
• can make petty renderings with a frame perf rendering as PNG, etc

I am happy to try this and right code around this package. I just wanted your opinion of the due diligence of actually doing this with a SDF based system like this.

In another issue I raised the idea of using cogent renderer. cogent craft looks like a nice and preferment 3d rendering engine. The Plane example is simple and shows of the classic 3d CAD needs well enough for a decent sized project.

[soypat]

gsdf is not a framework for one to build a CAD software on in the classical "framework" sense. gsdf can facilitate 3D rendering, 3D meshing, 2D drawing and whatnot giving you dead-simple access to GPU or CPU compute to evaluate SDFs, but that is it.

gsdf will not:

• Render arbitrary scenes with specific lighting, textured shapes.
• Tell you how to define a 3D scene
• Integrate with higher-order CAD tools and formats (maybe I'd go as far as STEP file format, but honestly I think that should probably [read as definetely] be a separate Go module)

gsdf can/will:

• Provide SDF primitives and operations that can then be evaluated on GPU/CPU
• Facilitate GPU/CPU evaluation of SDFs as a data pipeline (i.e meshing triangles) or as a visualization pipeline (i.e UI visualizing of SDF, fragment shaders)
• Render a SDF to visualize the shape
• Integrate with common basic CAD formats that can represent a SDF (to within a given tolerance) such as triangle/tetrahedron meshing

Anything lying out of the scope of gsdf should be a separate package and make use of gsdf interfaces which are currently pretty well established and proven to be suitable for high performance compute, reaching speeds orders of magnitude faster than OpenSCAD, sdfx, fogleman/sdf, soypat/sdf.

Why? Because I plan gsdf to be the foundation to building an ecosystem of diverse CAD projects such as for Electronic Design Automation (EDA), Part design (classical CAD), simulation (FEM/FEA), drawing and plotting (Inkscape, matplotlib). I wish gsdf to be simple, powerful, flexible and stable.

[gedw99]

Thanks @soypat

That’s pretty much what I am trying to do . My industry sector is called AEC. It’s a nightmare because of listed software and custom formats. I think this is also your predicament in your section .

was hoping for an AST description file to describe a bolt and then render it .

Then parametrics is possible at runtime by relating 1 ast file others using composition patterns.

So you can build larger projects where some variable in the AST describes a bolt instance or many bolts and those bolts influence that staircase which influences the handrails , etc, etc .

Volumetric computations of various kinds can be done too because the ast is loaded up into a 3d gui but also some golang engine that can understand the SDF

[gedw99]

Looking into it further it’s pretty much what I said but not quite as abstracted yet .

you load a scene using golang , render it , export a png / and stl of it.

the thing is that the scene be loaded could loaded off a file format. The file format can describe the geometry and any meta data.

[soypat]

Really sounds like you are describing a .go file that uses gsdf to define the shape...

[gedw99]

Yes I see your POV.

I’m shooting for the next level up to allow domain experts , and not developers to use the system .

A golang runner that loads an AST ( a simple text file ) that describes the properties and is loaded by a generic golang systems.

I already do this for 2D systems, using deck for a science system used by scientists. They are the domain experts .

This is the 2D AST :

https://github.com/ajstarks/decksh/blob/master/test.dsh

It also outsputs to many formats at runtime using basic Unix piping over std io:

https://github.com/ajstarks/deck/tree/master/cmd

you can probably see how similar its is to your system. You load properties , calculate calculated properties and then pump out outputs .

It’s parametric at design time and runtime . Change one part of a .dsh and its ripples through the system at design time . No golang changes at all , just file watchers , and a Taskfile ( that’s runs anywhere ).

If we examine :

https://github.com/soypat/gsdf/blob/main/examples/gasket/main.go#L54

the calculated properties use simple maths that are equivalent to the calculated properties that decksh has that are calculated at runtime using built in functions that decksh supports.

Decks approach is showing an architecture that is simplistic, embraces Unix pipes to allow designers to work with 3D using your base architecture.

The base is there in gsdf :) I’m just presenting an approach that allows designers and not programmers to use it .

[soypat]

I'm not understanding what you are getting at- if decksh works for your users then use that? It seems it has solved the 2D visualization aspect.

[gedw99]

Yes deck is lovely , and works fantastically . I run it with benthos and it pipelines things together . The IDE is just doing basic mutations on the DSL files and benthos at runtime.

to cut to the chase , I am seeing the possibility to do the same thing with gsdf. You have the bones but not the parser of DSL text format yet . The bones are there though. Deck generates the golang instances off the DSL at runtime.

it also can calculate derived values like you do .

Payoff is domain experts can use it without golang compiler or being a dev. The IDE for deck is built in golang btw . There are a few different ones that people have written because it’s all agnostic .even seen one built with just htmx / golang . In the IDE you are modifying the DSL visually . It’s pretty easy because the system already can do the binding in the server anyway . The DSL is real time synchronised between the browser and the server using a simple bidirectional sync system. Once you get used to the DSL being your SRC and think that way it all just works.

Cost is no strong typing , but deck, for example has a runtime checker that is exact like go fmt ( but smarter ) that is automatically executed .

I’m just brain storming this out . Am not at all trying to hijack your project. You created this project because you had a need Andi don’t know what the driver are for you .

my need is a very basic 3D system that gets people that need to do stuff that is real work out of all the proprietary stuff and allow extension from that.

Each user in the system has a git repo that is a mono repo with all their DSL files and assets in it and git LFS turned in . GitHub is their hard disk . I need for Google drive etc . Ci builds run like they do for devs but you get you final formats out of it like any standard 2D or 3D format that’s appropriate.

real time collaboration happens via them going to your server ( that runs on your laptop ) of the cloud ), and you and they edit in real time , altering your DSL files. Soft real time happens via traditional git sync , so that their fork of your repo catches up after the real time collaboration session .

[soypat]

You have the bones but not the parser of DSL text format yet

I'd hope the DSL parser is implemented in Deck because this is not the place for a DSL parser.

Payoff is domain experts can use it without golang compiler or being a dev.

I don't think I agree with your view. I've seen people avoid programming languages in favor of DSLs way too often when teaching people the basics of a programming language would have served the purpose far better and actually made the user's life easier. I think the aversion to programming languages is of semantic nature- they're both programming languages. You can build an API that is easy as a DSL to use in Go or Python. In fact I've deployed Python APIs for biologists with no programming experience with great success. Of course, good API design is key and is something I've seen be the cause people think DSLs are a must.

my need is a very basic 3D system ...

That is out of scope for gsdf.

I'd also suggest you avoid the loosely typed dynamic DSLs. OpenSCAD is a pain to program in because of this. If your users were to use gsdf sure, they'd need to learn some Go if you've never programmed before... but you'd need to learn the DSL anyways. Go is easy enough to edit if you start from a bare-bones example. there is also a huge amount of material on Go online and AI chatbots can easily help out your users with mistakes since there is SO much context for Go programs. Writing a DSL is also twice the work since you'd need to implement everything twice.

I think too often we put too little faith in our users. If our users can learn and use a DSL to design 3D parts they can CERTAINLY learn Go, or at worst not learn Go and let a AI write the program for them (eventually they'll learn anyways if they do it long enough). This is a textbook example of a case where AI code writing assistance can replace the need of a DSL entirely.

[gedw99]

I get ya drift about if they can use a DSL they can use go, and your not wrong.

Indeed scientists can code too. I designed for plugins for the ones that want to code and DSL for those that cant or won't, and a DSL checker to help keep it all together at runtime.

am going to close this one .. . hanks again @soypat for thrashing it out with me.