starseeker (Jul 30 2024 at 00:01): starseeker (Jul 30 2024 at 00:01):Um. Is Qt3D losing momentum? https://lists.qt-project.org/pipermail/development/2024-March/045127.html
starseeker (Jul 30 2024 at 00:11):Possibly relevant, if that's actually a KDAB dev: https://www.reddit.com/r/QtFramework/comments/1byxb0d/comment/lcnfahc
starseeker (Jul 30 2024 at 00:11):Ugh. If QtQuick3d is going to be the "recommended" stack, it's GPL...
starseeker (Jul 30 2024 at 00:42):@starseeker is beginning to wonder if a student project to look at what it would take to display BRL-CAD geometry in VulkanSceneGraph might make sense...
Sean (Jul 30 2024 at 04:35):Think options will be to A) live with it deprecated for now (probably not going away anytime soon), B) migrate to QVulkanWindow, C) embrace OSPray real time raytraced wholesale (which presently means GLFW or investment), or D) leverage an engine like O3DE (which is very active, uses Qt+Vulkan already). I think we probably just (A) for now, but (C) or (D) are very appealing.
starseeker (Jul 30 2024 at 12:20):Is O3DE more appealing than VulkanSceneGraph + vsgQt?
starseeker (Jul 30 2024 at 13:59):(Uh... btw, what does the octopus icon stand for?)
starseeker (Jul 30 2024 at 14:00):Can't speak for anybody else, but qged/libqtcad at least aren't using Qt3D, so we're not on the hook there - we just use the Qt OpenGL widget.
Sean (Jul 30 2024 at 21:22):starseeker said:
Is O3DE more appealing than VulkanSceneGraph + vsgQt?
Feature-wise and how I think it would truly accelerate our modernization: absolutely.
Architecture-wise, not more appealing -- but now that bext is working great, I think it definitely becomes an option on the table.
It's Amazon Lumberyard converted to Apache2. Active modern replacement to all the OSG/QGRE/VTK/etc options, alternative to the proprietary Unreal/Unity engines. Main alternatives would be Godot and Torque. VSG is certainly an option, but much much lower level target and (I think) a lot more glue work to develop an engine/framework around it at the end of the day.
Sean (Jul 30 2024 at 21:24):At least if we want to really do that thing you talked about a few years ago, being a proper visualization app-development platform (akin to Parasolid) for CAD-integrative apps like bob used to build..
starseeker (Jul 30 2024 at 22:38):Holy cow... O3DE Minimum hardware specification: 40 GB (using the pre-built installer ) or 100+ GB (depending on project configuration) of free disk space
starseeker (Jul 30 2024 at 22:38):And I thought LLVM was bad...
starseeker (Jul 30 2024 at 22:39):Apparently they have a requirement to use clang on Linux...
Sean (Jul 30 2024 at 22:39):Yup, it's been back-burnered because of how big it is -- we weren't in a position pre-bext.
starseeker (Jul 30 2024 at 22:42):That's... intimidatingly big. I think this is one of those "sit down after dinner and hash over for four hours" topics.
Sean (Jul 30 2024 at 22:43):I mean, not a decided deal -- I think Godot and VTK are solid contenders, all things considered. O3DE is definitely the most modern and feature-packed, used in AAA games, but at that disk pricetag. Godot is much smaller but much fewer features. VTK has even better display management support relevant for what we need for CAD, but then is massively lacking (in comparison) in terms of input events, overall app development, etc.
starseeker (Jul 30 2024 at 22:44):This may come down to one of those philosophical things, but I'm actually leaning much more towards the "develop components and glue them together into apps" approach as opposed to "build a lot of apps on top of a framework."
Sean (Jul 30 2024 at 22:45):I've charted out a whole matrix of considerations more than a few times just in the past couple years.... More than a dozen considered. Even originally had unity and unreal in that list just to make sure I wasn't being bias-blind, but their licensing really is a problem.
starseeker (Jul 30 2024 at 22:46):Am I incorrect that adopting any of those frameworks would basically mean wholesale replacement of MGED/Archer?
Sean (Jul 30 2024 at 22:48):wholesale replacement of Tk and custom opengl drawing
starseeker (Jul 30 2024 at 22:49):That's a very heavy lift. Even with the consciously "refactor and reuse, stay close to what we do now" approach I've been taking with libqtcad/qged, there's still a lot in MGED (editing, in particular) I haven't reproduced feature wise yet. If we stick to the "maintain feature parity" rule...
Sean (Jul 30 2024 at 22:49):still with an embedded/embeddable ged command context in some form, but the drawing display is a big "it depends" on where we're at with fast robust tessellation vs realtime ray tracing vs alternatives.
starseeker (Jul 30 2024 at 22:50):The editing depends on vlist wireframe display - were we going to abandon that in favor of some representative mesh/raytrace visual?
starseeker (Jul 30 2024 at 22:51):Every time I dig into it, wireframes are a really lousy fit for most modern systems...
Sean (Jul 30 2024 at 22:53):Well that's part of the appeal of something like godot or o3de vs what we've historically done. Having to write such detailed input bindings to editing controls in particular is not something that we'd have to implement, at least not to such a custom un-translatable extent.
Sean (Jul 30 2024 at 22:57):starseeker said:
The editing depends on vlist wireframe display - were we going to abandon that in favor of some representative mesh/raytrace visual?
I mean, I would want the ability to display a wireframe still, but probably not defaulting to it. The idea really is "let's approach this if we were starting fresh" while leveraging librt/libged/etc as much as now if not more, but also letting the engines do what they do best (scene/asset management, picking, menus, app state management, preferences, updates, gui panels, display pipeline customization, default pbr rendering, and more...)
starseeker (Jul 30 2024 at 22:59):Hmm. OK. Well, at least for the short term then my "next steps with qged" will also be directly useful for that sort of thing (or at least I would expect them to be) so it's not one of those "must decide now" issues.
Sean (Jul 30 2024 at 23:01):That's a boatload of coding we don't even really think about but is essential in most modern app dev. MGED and Archer do a lousy job of standard app expectations, doing the minimum on menus/panels/prefs/etc. Qt gives us a good bit of some of that, but definitely not for free -- we have to code up every single aspect whereas an engine would give us a ton of that literally for free.
starseeker (Jul 30 2024 at 23:03):What would a proof of principle look like? Exposure of a ged command line and basic scene visuals within one of the engines?
Sean (Jul 30 2024 at 23:11):starseeker said:
Hmm. OK. Well, at least for the short term then my "next steps with qged" will also be directly useful for that sort of thing (or at least I would expect them to be) so it's not one of those "must decide now" issues.
Probably, but it really does depend what direction and state we end up on for the main display, how drawing is going to happen.
With an engine, we'd probably rely heavily on automatic meshing during load and caching meshes, as their strength would be in giving them geometry and letting them do the drawing. With something like an integrated OSPray, we could avoid the meshing, but more unknowns (and technical complexity to integrate). With both approaches, I think we'd be directly leveraging all the high-performance wireframe extraction you set up for qged (and of course the cli).
A game engine would be adopting an "app container" that we'd spend time customizing look, feel, and presentation aspects, and get the rest for free. VTK would shift effort from customization to the overarching app, input bindings, and more coding overall (guess, but probably). Custom Qt track we were on can also work, but I've come to the conclusion that's going to require the most coding overall (at least to get parity), which practically will mean less functionality and/or less time to production usability with a higher long-term development than we'd have with the alternatives.
Sean (Jul 30 2024 at 23:11):starseeker said:
What would a proof of principle look like? Exposure of a ged command line and basic scene visuals within one of the engines?
Exactly.
Sean (Jul 30 2024 at 23:14):I think doing that we'd have functional view-state parity automatically and with some basic entity (i.e., object type) definitions in the framework, we'd get edit-state parity pretty darn quickly. The hierarchy is unknown if they can handle our scale with their default controls, but then you have code that does that so we could just wire that up as potentially the only customization needed.
starseeker (Jul 30 2024 at 23:15):My next step is actually to dig into command line editing via some form of the "edit" command (and probably a revamp of my libged database model - when I shifted gears, I had seen just enough to know I'm not properly robust yet to the geometry being edited.) To divorce the editing from the GUI as much as possible, edit will be needed . ged_exec is also presumably how we'd want to expose the low level editing operations in any other GUI, so that much at least should be universally useful. Making Qt widgets for the various primitives, and action filters, will be Qt specific but should also help establish the necessary patterns and prove out the lower level capabilities.
starseeker (Jul 30 2024 at 23:17):If I can figure out some way to auto-generate Qt widgets based on a JSON template or something provided by the primitives that'd be cool... just a notion, dunno if it's practical
starseeker (Jul 30 2024 at 23:18):Definitely wouldn't fly for something like brep, bot or dsp but a lot of the implicits ought to be doable that way, really...
starseeker (Jul 30 2024 at 23:18):If I'm really greedy I'd like to use those same descriptions for constraint evaluation... I've always wanted to revisit that gecode experiment from all those years ago
Sean (Jul 30 2024 at 23:19):Note O3DE is Qt under the hood so anything we do in Qt should just work as-is. You still customize input bindings and such via Qt slots/signals - they just define a whole slew of automatic bindings for us so things like view controls and other things one would want in a game / 3D environment come for free.
starseeker (Jul 30 2024 at 23:23):Hmm. That might actually be a reasonable "have our cake and eat it too" answer - a "minimalist" Qt interface that has the key widgets but not the fancy stuff if O3DE isn't available, and the same components plugged into a snazzier interface if disk space and RAM are no object.
starseeker (Jul 30 2024 at 23:24):If they're embedding Qt for UI elements, I'm beginning to understand why their disk footprint is so big... I wonder how long it takes to compile?
Sean (Jul 30 2024 at 23:26):Might also make it possible to deploy an OSPRay+Qt interface first with a hierarchy and command line, aim to be mged-compatible. Give time to prototype with O3DE separately for even better display and app management, more advanced controls, assess the costs and risks more directly.
Sean (Jul 30 2024 at 23:26):I compiled o3de apps a year ago just poking around and it took less time than bext, haha...
starseeker (Jul 30 2024 at 23:27):The thing I've always worried about with OSPRay is how to handle things like text labels, rtcheck output, etc. - it's great for geometry, but we'd basically have to generate geometry that could be raytraced on the fly for all those. Not sure how hard that would be to get right
starseeker (Jul 30 2024 at 23:27):They must not use LLVM
starseeker (Jul 30 2024 at 23:28):Or maybe there's more stuff I can turn off in bext <evil grin>
Sean (Jul 30 2024 at 23:28):I mean, it's so fast that all the plot data could literally be thin cylinders injected into the view, but it's still possible to just issue draw commands in a separate pass.
Sean (Jul 30 2024 at 23:30):text labels are easily handled as we'd just draw text into the viewport. It does that now to identify "BRL-CAD" and a version number.
starseeker (Jul 30 2024 at 23:31):So basically we'd need a custom version of the draw command that served things up to OSPray and did a second pass to overlay the OpenGL calls that would still be needed...
Sean (Jul 30 2024 at 23:31):worst case IFF there was any problem, we'd just put the text information in a separate panel instead of as an overlay, but I don't think it's a problem either way
starseeker (Jul 30 2024 at 23:32):Would we replace/rebuild faceplate with imgui or some such?
starseeker (Jul 30 2024 at 23:33):Right now I think that's still how a fair number of the CSG primitives end up getting edited IRL
Sean (Jul 30 2024 at 23:34):Like I said, I'm 99% sure we can just draw faceplate ourselves even the same way we currently are, but yeah -- the footer could be stashed into a qt footer panel (we'd still want to leverage/present hierarchy and cmd windows).
starseeker (Jul 30 2024 at 23:35):It's not just drawing though - it needs mouse interaction awareness. How would that work in an OSPray window? (I guess mouse events would be GLFW's problem?)
Sean (Jul 30 2024 at 23:36):You talking about faceplate menu also? That has modality in it...
Sean (Jul 30 2024 at 23:36):I was thinking faceplate footer mostly, since that's the critical info
starseeker (Jul 30 2024 at 23:37):Yeah - the one that lets the modeler select which primitive parameter to manipulate
starseeker (Jul 30 2024 at 23:37):Ah - yeah, the footer is much easier - with the fontstash layer I've got that working with swrast too, IIRC
starseeker (Jul 30 2024 at 23:40):You know... that might actually be a really interesting starting exercise for having the primitives generate a list of editable parameters for apps to use. In theory, such an input ought to be usable to generate a faceplate menu implementation.
Sean (Jul 30 2024 at 23:40):OSPRay doesn't do any GUi -- that's still up to us, whatever we put OSPRay into and whatever we pair it with. I wouldn't think ImGUI, I'd expect it to be Qt widgets, so that is no different effort as Qt+OSPRay or O3DE+OSPRay for things like faceplate.
starseeker (Jul 30 2024 at 23:41):Oh, OK - so drawing Qt widgets on top of the scene render?
Sean (Jul 30 2024 at 23:41):Right
starseeker (Jul 30 2024 at 23:41):That used to be hard back in the day - I hope it's gotten easier ;-)
Sean (Jul 30 2024 at 23:42): Sean (Jul 30 2024 at 23:43):Note they conveniently picked powerplant as the demo as well as a non-trivial render mode, but that's the idea.
Sean (Jul 31 2024 at 00:09):/me gets MoltenVK (Vulkan) demo working on Mac.
Francine Vieira (Aug 29 2024 at 09:24):
Francine Vieira (Aug 29 2024 at 09:25):Francine Vieira said:
Last updated: Oct 09 2024 at 00:44 UTC