whitequark changed the topic of #solvespace to: SolveSpace--parametric 2d/3d CAD · latest version 2.3 · http://solvespace.com · code at https://github.com/solvespace/solvespace · logs at https://irclog.whitequark.org/solvespace · message channel op if you can't talk
cr1901_modern has joined #solvespace
q3k has joined #solvespace
<q3k> hm, has anyone tried to export a solvespace model (as .step?) into kicad/horizoneda?
<q3k> export -> 3d wireframe (stp) seems to create 'empty' (no visible geometry to horizoneda and some rano online viewer) files
<q3k> oh, do i need to export -> surfaces instead?
<whitequark> yeah
<q3k> hm, horizon still doesn't like that
<q3k> (it uses opencascade iirc)
<q3k> okay, at least betasharecad.org seems to like it now
<q3k> although no colours.
<q3k> i'll ask the horizon dev then
<whitequark> no colors are expected
<whitequark> solvespace uses a handwritten step exporter
<whitequark> it is very bad
<q3k> hm
<q3k> does any of the export formats support colors, so I can string some unholy abomination of format conversions?
<q3k> that doesn't look right
<q3k> (flipped normals? do step files even have normals?)
<q3k> (this is the autodesk online viewer)
<whitequark> q3k: stl should support colors
<whitequark> step files have... issues
<whitequark> this is well known
<q3k> i see
<whitequark> the format is an unholy abomination
<whitequark> look at it
<q3k> i have accidentally vimed it
<q3k> i'd rather not do that again
<whitequark> this isn't even a bad step file
<whitequark> it had most of the junk trimmed from it
<whitequark> most of them are much worse
<whitequark> this also explains the lack of step import btw
<q3k> let's see if reeCAD can take care of the STL->STEP conversion
<q3k> *FreeCAD
<q3k> although that's also an appropriate name
<q3k> hm, freecad sees no colors in the .stl
<whitequark> hrm
<q3k> apparently colors in stl are an extension and freecad don't support that
<whitequark> I *think* the colors are there
<whitequark> oh
<whitequark> yeah it is
<q3k> hrmpf
<q3k> oh no
<q3k> it's one of _those_ standards
<q3k> whitequark: although it doesn't look like there's colour in the stl exporter, either https://github.com/whitequark/solvespace/blob/master/src/export.cpp#L849
<q3k> and .obj exports colors as .mtl, but freecad can't load them
<q3k> argh
<whitequark> hm
<whitequark> oh right, that was .obj
<whitequark> not .stl
<whitequark> sorry
_whitelogger has joined #solvespace
togo has joined #solvespace
f8l has quit [Ping timeout: 245 seconds]
f8l has joined #solvespace
<q3k> whitequark: RFC https://github.com/q3k/q3d/
<q3k> (afk for two hours or so, i have an exporter for this in solvespace ready, will send a PR when i'm back)
balrog has quit [Ping timeout: 250 seconds]
balrog has joined #solvespace
<whitequark> AMF: designed by a drunk committee, closed ISO spec
<whitequark> lmao
<whitequark> COLLADA: designed by a batshit insane committee
<whitequark> q3k: request: RGBA color
<whitequark> solvespace already uses that
<whitequark> q3k: request: three normals and not one
<whitequark> with one normal you wouldn't be able to represent certain kinds of geometry
<whitequark> like uh
<whitequark> imagine a smooth sphere and a golf ball like sphere
<whitequark> same mesh, different normals
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #solvespace
<q3k> whitequark: yeah, i was thinking about how to allow for both face normals and vertex normals
<q3k> whitequark: maybe a mesh enum, NO_NORMALS (calculate face normals from tri) FACE_NORMALS (use given face normals) and VERTEX_NORMALS
<q3k> whitequark: this makes the format less trivial to use though, because you have to check that first
<q3k> whitequark: and for alpha in face colours, i have mixed feelings
<q3k> whitequark: mostly because alpha in a triangle mesh doesn't really make sense?
<q3k> whitequark: it makes sense in a volume, if anything
<q3k> whitequark: i'll have to think about it, and at least specify what 'alpha' exactly means
<q3k> whitequark: pushed some changes to the spec, ptal
<whitequark> q3k: ack re: alpha
<whitequark> let's omit it for now
<q3k> it's there, defaulting to ff, defined to only concern front-facing faces and only for rasterization rendering
<q3k> which should be okay for now
<whitequark> ok, let me see
<whitequark> Units other than millimeters: No.
<whitequark> thanks
<whitequark> q3k: you should specifiy explicitly whether alpha 0 or alpha 1 is "opaque"
<whitequark> I think it's technically not ambiguous
<whitequark> but it's not very clear
<q3k> ah yes, will do
<whitequark> does your solvespace exporter fail on non watertight meshes?
<whitequark> it should according to this
<whitequark> this should be called vertex1 vertex2 vertex3
<q3k> so i'm not sure what to do with meshes that do not form a volume
<q3k> maybe i overdid it with the full tesselation requirement
<q3k> so considering i made a few other things less strict, i guess there shouldn't be such a requirement
<q3k> and the consumer will check for that if it needs it
<whitequark> yeah
<q3k> not much else i can do for a tri mesh
<q3k> pushed changes