I did not really solve - just found a suitable workaround for the binding generator. The workaround being specifying extra includes for the problematic headers.
I don't want to go too much into semantics, but what you state sounds more like a reason why it was not caught by the OCCT devs and not a reason for it being or not being a bug. Either way, it is still not clear to me if this situation is intentional and I don't know how the "correct" order of...
Random example when doing my static analysis:
[W 211205 11:52:10 translation_unit:47] ./opencascade/IGESSolid_ToolBlock.hxx
[W 211205 11:52:10 translation_unit:48] dummy.cxx:79:104: error: unknown type name 'Standard_OStream'
AFAIR I had similar issues whe wrapping 7.5. Every now and then...
I'm working on OCP 7.6 and (again...) I see a lot of missing includes in some OCCT headers. Sloppy coding or am I missing something (i.e. some headers are not meant for consumption)?
Relevant devroom:
https://fosdem.org/2022/schedule/track/libre_and_open_hardware_cad_modelling_and_vlsi/
Maybe those as well:
https://fosdem.org/2022/schedule/track/open_research_tools_and_technologies/
https://fosdem.org/2022/schedule/track/open_source_design/
I'd like to have better offset surfaces (more robust), better skinning (approximation, constraints) and gordon surfaces. Otherwise just looking around.
DA,
I'm trying to assemble a list of open source implementation of NURBS-related algorithms (besides / on top of OCCT). Here is what I have so far:
http://ayam.sourceforge.net/
https://github.com/ssg-aero/gbs
https://github.com/DLR-SC/tigl
https://gitlab.com/ssv/Mobius/...
With vtk.js I had to tune the params somewhat. I tried also with regular vtk (9) and it seems that this combinations gives quite nice results:
mapper.SetResolveCoincidentTopologyToShiftZBuffer()
mapper.SetResolveCoincidentTopologyZShift(0.2)
I wish I understood what I'm doing.
To be more specific, this is the most interesting paper:
Liu, Xiaodong. "Filling N-sided holes with trimmed B-spline surfaces based on energy-minimization method." Journal of Computing and Information Science in Engineering 15.1 (2015).
Another approach that would be nice to try (or maybe even...
@Quaoar regarding the glitches in VTK are you aware of setResolveCoincidentTopologyToPolygonOffset (see https://discourse.vtk.org/t/edge-rendering-issues/7175 and https://vtk.org/doc/nightly/html/classvtkMapper.html#ab93c3652abaad9ec53b636bb63073cd8 )?
Not a lot. Papers of Xiaodong Liu did indeed caught my attention. If I ever am going to do something like this I'll indeed try an optimization like approach with soft constraints and look into optimizing parametrization too.
Probably this is similar to the suggestion of DanB: you know in principle which trinagles are connected and you can map back the intersecting points to triangles so it should be possible to reconstruct the connectivity this way.
Yes, I see it too. It only happens with the axes helpers (AIS_Line objects AFAIR). If you hide them (untick the boxes next to XYZ) it will render fine. It never bothered me so I did not investigate. Help will be always appreciated :).