Please bear with me in this rather long question.
I am currently building a voxel engine (nothing like Minecraft, don't worry). I want the engine to be modular. For example, I want the voxel 'engine' to be a seperate component to the 'renderer'.
The engine currently builds up a database of voxel objects that are each composed of a 3-dimensional array. However, the renderer makes use of meshes extracted from this data using the marching cubes algorithm. I need to store both the voxel data and the mesh data for each voxel object. However, since both components are modular they cannot be stored in the same place.
My current solution has been to build a secondary data structure inside the renderer that attempts to mirror the engine. It does this by duplicating the objects in the engine structure, giving each object a pointer to the object they mirror. However, this quickly becomes complex, since modifications to the original data structure have to be updated by the mirrored version.
As you can see, the problem is more theoretical than technical. Could anyone help me in suggesting an OOP structure that my program may take to solve this issue better? I'm open to all suggestions, however radical.
Thanks.
Related
My scene currently consists of a huge topography model (Mill. Verticies). Now the scene becomes more complex and contains many smaller 3D objects. Does it make sense to switch from a QFrambufferObject (with C ++ / OpenGL) to Qt3D?
What about the speed?
Which file format (Wavefront OBJ, Stanford Triangle Format PLY, STL (STereoLithography)) is suitable? I am currently loading the data from the .hgt format into a vector array and then into the QFrambufferObject.
With Qt3D, is it possible to load only the tiles in the graphics card that are currently visible in the viewport or to delete them as soon as they leave the viewport when the camera angles change?
That's difficult to say. I assume by
Does it make sense to switch
you mean will it be fast enough. Regarding your two points:
Qt3D uses assimp internally to load models, so if that library is able to load hgt files, so should be Qt3D.
What do you mean by reload? Do they change dynamically in the model? Or do you mean re-render? There's QFrustumCullung but that seems to render the whole entity still. Do you know whether your object consists of multiple parts? Because when Qt3D loads models (i.e. whole scenes) from files I think it persists its structure. If your model is split into multiple standalone components it could be that QFrustumCulling improves rendering speed because they don't get drawn when they are not viewed.
I personally feel like Qt3D is slower compared to a hand-crafted renderer in OpenGL. But it constantly improves so if it doesn't take long to try it out maybe it's worth a shot. Also, the flexibility of Qt3D might make up for the slower rendering speed.
My PhD project revoles around simulating the paths of photons through objects of different optical properties. My code has classes which create ccd images etc, but it would be much more useful to be able to create a simple rendering of the 3D objects and the paths the photons take through them.
I've written an opengl system for viewing such a scene, but it would be much better if I could use something much more lightweight where I could simply specify the vertices of an object, and then a photon path as a list of connected vertices.
Exporting all the data and then visualising it in another program isn't ideal, as things like mesh transformations need to be taken into account, and I'd rather avoid exporting several new mesh objects just to import them all into another program.
What I essentially need is to be able to create the three dimensional equivalent of a svg image. Does such a '3D scene' file format with a simple visualiser exist?
I write in C++ on MacOS, though I'd prefer to avoid using a visualisation library. I appreciate that what I'm asking for is rather niece and picky, but that's why I'm asking the internet as someone might have come across a similar need for such a tool.
Suppose I have two meshes stored in any sane format (e.g. wavefront .obj or collada .dae), and I want to combine them into one mesh programmatically. More precise, I have a landscape and an object as two meshes. I want to put object into landscape after performing transformation to it, so it gets on the right place, and export this as result model.
As far as I understood, in assimp there is something similar named SceneCombiner, yet it seems that this is internal structure and has no interface (even though here https://github.com/assimp/assimp/issues/584 the ticket concerning it is closed, I couldn't find out how to use it).
Maybe I should use CGAL or something like that? I don't have very much experience in CG libraries, so any advice will be really useful!
You can do that with CGAL. You would read two meshes, and the call copy_face_graph(), and then write the mesh back.
I am developing a 3d facial animation application in java using opengl(jogl) i had done the animation with morph targets and now i am trying to do a parametrized facial animation .
I can't attach the vertex of the face with the appropriate parameter,for example i have the parameter eyebrow length ,how could i know wish are the vertex of the eyebrows (face features),please please could anybody help me i'm using obj file to read the face model and face gen to create it.
I appreciate your help .
For each morph target you assign each vertex a weight, how strong it is influenced by the respective morph target. There's no algorithmic way to do this, this must be done manually.
Lightwave OBJ file format may not be ideal for storing the geometry in this case, since it lacks support for storing such auxiliary data. You may extend the file format, however this will probably clash with programs expecting a "normal" OBJ.
I strongly suggest using a format that has been designed to support any number of additional attributes. You may want to look at OpenCTM.
What is the best method to store 3d models in game ?
I store in vectors:
vector triangles (each triangle contain number of texcords, numer of vertex and number of normal),
vector points;
vector normals;
vector texCords;
I'm not sure what constitutes "the best method" in this case, as that's going to be situation dependent and in your question, it's somewhat open to interpretation.
If you're talking about how to rapidly render static objects, you can go a long way using Display Lists. They can be used to memoize all of the OpenGL calls once and then recall those instructions to render the object whenever used in your game. All of the overhead you incured to calculate vertex locations, normals, etc are only performed once when you build each display list. The drawback is that you won't see much of a performance gain if your models change too often.
EDIT: SurvivalMachine below mentions that display lists are deprecated. In particular, they are deprecated in OpenGL Version 3.0 and completely removed from the standard in Version 3.1. After a little research, it appears that the Vertex Buffer Object (VBO) extension is the prefered alternative, though a number of sources I found claimed that performance wasn't as good as display lists.
I chose to import models from the .ms3d format, and while I may refactor later, I think it provided a decent foundation for the data structure of my 3D models.
The spec (in C header format) is a pretty straightforward read; I am writing my game in Java so I simply ported over each data structure: vertex, triangle, group, material, and optionally the skeletal animation elements.
But really, a model is just triplets of vertices (or triangles), each with a material, right? Start by creating those basic structures, write a draw function that takes a model for an argument and draws it, and then add on any other features you might need as you need them. Iterative design, if you will.