Closed ptheywood closed 4 years ago
Requires:
Options: SFML vs SDL2 (SFML is similar in offering to SDL2, however has an OOP interface). Then i can start fiddling with it when I have free time.
We now have Circles model, and in checking that I was using an external visualiser which shows the value this would add.
Still unsure of the best API for this, perhaps something like.
CUDAAgentModel model = ....;
Visualisation v = model.addVisualisation();
// Check's agent is valid
// checks it has x, y, (z) variables? (if not, should a user need to specify as 2nd, 3rd, 4th args var names to use for location.
// If model is 2D we use orthographic projection with ability to scroll/zoom, 3D pretty standard noclip camera
// Maybe allow user to opt for 2D vis of 3D data?
AgentVisualisation &av = v.addAgent("myAgent");
// Choice from basic stock models, provide own to be loaded
// Maybe also optionally specify model dimensions here
// Configuring on agent sets the default value for all states
av.setModel(Models::Sphere);
// This is the model matrix used to transform model relative to it's location
// can scale, rotate, translate
// harmless if it's just left as the identity matrix
av.setModelMatrix(glm::scale(1.0f));
// Can instead action StateAgentVisualisation to configure state specific visuals
StateAgentVisualisation &sav = av.State("foobar");
av.setColor(1.0, 0.0, 0.0);
// Need a way to configure shading/colouring(/texturing?)
// Most simple would be to have them specify a tertiary variable and HSV bounds from a colour wheel to lerp between.
// As possible method would be to wrap each 'shader mode' inside a bespoke class with a common interface. So that users can configure the shaders in a more intuitive manner. (Need to think on how that would be best structured though.
// More complicate models, e.g. PED are going to require far more advanced visualisation tools
// e.g. load a 3D model for environment (adding static models should be fine tbh)
// maybe a second class of `AgentVisualisation` for two keyframe animations? This would reduce need for people to dig around in shaders, and handle all the back-end fuss of loading a 2nd model and passing it to the shader
// Obviously a version with raw shader access would be nice, but that's probably going to be limited to basic single model, without people literally writing a custom agent vis type to dev with.
// TODO
// Show the visualisation window
// Drop it into a second thread at this point and block further changes
v.activate();
// Execute the model as configured
model.run();
// Sim has completed, close visualisation
// Could leave it open, and call something like join() instead, which spins
// This would allow user to explore the end state whilst blocking the main thread until they manually close the window.
v.deactivate();
The above example neglects to consider stateful models. Agents are stored by state, and thus will be rendered per state. It then becomes necessary to differentiate states via colour/texture/model.
I expect the majority of this won't be too painful to add in as a second 'optional' repo, but I wan't to be sure about the API before I start as it would be very easy to hack in a visualisation that is non-flexible.
A good addition to visualisations would be the ability to represent agents with 2D textured sprites. This is more applicable to 2D visualisations, but it could potentially make models such as predator prey alot clearer.
PedestrianLOD example visualisation would require agent sorting (#52)
CMake strategy for this
FGPU2_dev Cmake, has visualisation option, when enabled:
FGPU2_VISUALISER
macro, to turn on the visualiser methods.If both repos pull in GLM
independently, unsure if this will be a problem.
Having started on the example above, I'm unsure of the best separation between the two repos.
The three main classes above ModelVis
, AgentVis
, AgentStateVis
, need access to the model data/description hierarchy so are maybe best placed to create essentially a visualisation description. When ModelVis::activate()
is called, this could be handed off to the separate repo, as it should be agnostic of FPGU beyond that point.
I think I might continue in this direction and try to get it working with only the ability to specify an agent (and it's location vars). From there I can tack on the elements of customisation.
FLAME GPU 1 provides a simple visualisation tool, and the ability to implement custom visualisations.
This may be a separate tool for FLAME GPU 2, for real-time visualisation and/or playback visualisation from a collection of output files (or similar)
Work is ongoing in a separate repo: https://github.com/FLAMEGPU/FLAMEGPU2_visualiser
This should be pulled in by CMake changes in
visualisation
branch, but a new option must be enabled.