Ideeën
Een product is meer dan zijn geometrie
Ik begon een eigen geometry kernel te bouwen omdat ik configureerbare producten sneller en eenvoudiger in de browser wilde kunnen genereren.
Een werktafel als kernelprogramma: plaatwerk, multiplex en kokerprofiel.
Plaatwerk, profielen, uitsparingen, verstekken. Geen volledige CAD-vervanger, maar een lichte technische basis voor configuratoren. De technische playground staat op kernel.kubuz.net.
Tijdens het bouwen verschoof de interessantste vraag. Niet hoe ik nog meer geometrie maak, maar hoe ik het product beschrijf zodat die geometrie maar één van de mogelijke outputs wordt.
Waarom een eigen kernel?
Voor veel configurators heb je geen volledig CAD-systeem nodig. Je wil een productvariant kunnen beschrijven, snel geometrie genereren, de gebruiker laten kijken en daarna bruikbare technische data overhouden.
Een klassieke CAD-kernel kan veel meer, maar brengt ook veel complexiteit mee. Mijn experiment vertrekt daarom vanuit een kleinere set die dicht bij workshopproducten ligt: platen, profielen, gaten, uitsparingen, verbindingen en samenstellingen.
JSON als grens
Ik wil dat een product via een duidelijke, machineleesbare beschrijving opgebouwd kan worden. Niet omdat JSON op zichzelf bijzonder is, maar omdat het een simpele grens vormt tussen productkennis en de systemen die er iets mee doen.
Een configurator kan het schrijven. Een viewer kan het lezen. Een agent kan het aanpassen. Een manufacturinglaag kan dezelfde informatie gebruiken om output te maken. Dat werkt alleen als de betekenis van die data scherp genoeg is.
De kernel zelf heeft geen formules. Als je hierboven lengte, breedte of hoogte van de werktafel verandert, schrijf ik de poses opnieuw uit vanuit die primaire maten. Dat is bewust. De geometry engine bouwt wat je haar geeft. Wat het product betekent, zit daarbuiten.
Van geometry naar semantics
Geometrie vertelt waar een gat zit. Ze vertelt niet waarom dat gat er zit, aan welk onderdeel het gekoppeld is, welke optie het activeerde of welke productieregel erop van toepassing is.
Daarom onderzoek ik boven de geometry kernel een semantische laag. Concepten zoals Parameter, Component, Profile, Plate, Material, Constraint en Relationship krijgen daar een vaste betekenis. De kernel wordt dan niet het productmodel zelf, maar één engine die uit dat model geometrie kan maken.
Dat verschil is de reden dat ik dit onderzoek.
Ongoing research
Dit is nog onderzoek. Ik gebruik de kernel om modellen te bouwen, grenzen te vinden en te testen welke abstracties overeind blijven zodra producten complexer worden.
De werktafel hierboven is zo'n test: een geplooid werkblad, multiplex in het kader, kokerprofiel en een of twee schappen. Geen mates. De poses komen uit een paar maten. JSON, meer voorbeelden en de editor staan in de kernel playground.
Sommige ideeën zullen verdwijnen. Andere zullen waarschijnlijk doorschuiven naar configuratoren en engineering tools. Dat proces wil ik hier ook tonen.