Jump to content
  • Advertisement

recp

Member
  • Content count

    46
  • Joined

  • Last visited

Community Reputation

216 Neutral

About recp

  • Rank
    Member

Personal Information

Social

  • Github
    recp
  • Steam
    recpa

Recent Profile Visitors

2741 profile views
  1. To get center of single mesh, getting center of AABB seems fine (only for single mesh), but summing all faces could give wrong center. Because if that mesh has more detail at one side, this means that there are lot of faces at that side, then center point will be close to that side. Because I did similar to your proposal except I summed all positions instead of faces centers. For second part, if there are multiple objects at one side and less objects at opposite side then center will close to multiple objects' side. I tried this and center is not accurate because of the reasons I mentioned above, maybe I miss something?
  2. 1. In editor and viewer, I'm using the center for trackball to rotate mesh/node/scene around its center. Rotating around origin, if it is not same as center is not good for trackball. Maybe rotating around arbitrary point would be an option too but rotation around its center is default for trackball. It is expected behavior if trackball is attached to that model/mesh to rotate it. 2. I want to apply rotation animation around its center (not around its local origin) like Unity's spinning cube example (https://unity3d.com/learn/tutorials/topics/scripting/spinning-cube). I'm using this method (http://old.cescg.org/CESCG-2002/DSykoraJJelinek/, see Basic intersection test) for frustum culling, center point is not involved for culling. You are correct, I used average center (it is average of all sub mesh's centers) and it is not accurate (or it is not geometric center) as you said 😢 😢 For instance if there are two center point at right and one at left, main center is close to right. But unlike my before implementation (I was used center of AABB which is combined of all sub AABBs; centerOfAABB = (min + max) * 0.5), the center is not moving over time after rotation is applied. At this point, I can continue to implement animation system (trackball is already working) and I can back later for this after animation system is implemented. Since my center is not accurate, I must use an alternative way and it seems I must use spheres for getting accurate center point. I added this to my TODOs. Since it is open source on github, I would like to share/introduce my animation system as code samples to demonstrate what I'm trying to do after finished 🤗
  3. UPDATE (Solved): Averaging each primitive's center to get center point for mesh/model and averaging each mesh/model's center to get scene's center worked for me. It seems I had a bug before, I updated the way to get center for scene and now center is not moving after rotation applied as I wanted. For some scenes rounding errors occur but it is smaller than epsilon (1e-5) and it is acceptable. Currently it uses AABB's center and I also added an option to use exact center, when this option is enabled importer (not render engine) computes exact center (centroid) by averaging all positions. Users can also specify a custom point as center. This makes engine very flexible I think. To summarize it, instead of re-calculating center, it uses pre-defined center. After transform is applied to a model, the center also gets transformed. If users don't specify custom point or force to use exact center then center of AABB will be used. Thanks everyone for comments.
  4. How can I calculate position of center? This is the actual question from the beginning. Maybe I can calculate the center of mesh while importing mesh by averaging all positions data (for single mesh)? Then I can store it in model/primitive structure. After transform changed, that transform could also be applied that pre-computed center. Averaging all these pre-computed centers (after transform applied) could give center of scene? Render engine would only need to apply transform, all jobs will be done in importer. Is this good or bad idea? Because to get an AABB, importer already iterates all positions data for each mesh. @Gnollrunner would this be better alternative instead of using smallest spheres?
  5. Yes I think this is correct, "a point" must be center/centre of object for my case. I'm trying to find that centre, this is the actual issue. I'm not maintaining a separate origin, as you said I'm just trying to visualize a node changing its rotation around a point (center of object). You see, what I want to do is very simple
  6. Currently I'm working on animation system, after that yes it will be involved. It is next TODO so I can't say much for now. I thought that I can use same AABB boxes for that purpose. I'm only re-calculating center if parent transform changed. Because if object may move, then I have to re-calculate it, right? I want to rotate object using trackball, since it is trackball it must rotate around object's center, not origin, if origin could be (0,0,0) in object space. Also I want to animate object around its center. Not related to other models just around its center. But a model may have multiple primitives so center must be center of all primitives of model/mesh and center of scene must be center of all models, I think As @Gnollrunner mentioned maybe sphere can fix this issue, because after transforming AABB, the shape of AABB is changing, so center of model/scene/node also changing. This means that the scene is moving by time just because of this. I used average center (sum of all AABBs centers / AABB count), it seems work. There is rounding errors e.g. center1 = (100.234, 10.095, 78.356), center2 = (100.201, 10.101, 78.4), but better then nothing.
  7. Exactly! I want to keep same point as center after rotations are done. Do you suggest to drop AABB completely and switch to sphere or keep both? When trackball is attached to a model, a node or a scene; it must use exact and same center. You may rotate object using trackball, then drop mouse then rotate it again, this is why it must use same center. Trackball is just one case. For instance rotating scene/node around its center can be animated. If center will move, it will also move scene/node. After a while, all scene will be moved there will be nothing to render Thank you ver much, I will give a try later.
  8. No I already have bounding box which is Axis Aligned Bounding Box (AABB). Thanks for sharing that algorithm, I'll take a look at it later. I want to rotate scene or a node around its center, this is all I wanted To do this I need center point of scene or node. All primitives already have Axis Aligned Bounding Box (AABB). So I'm calculating center of primitive like this: center of primitive = (aabb->min + aabb->max) * 0.5 But I don't know center of scene or center of node. A node or model may have multiple primitives. I need average center of all of them to make rotation work correctly. You can think primitive as sub-mesh, and model as mesh. Using spheres instead of AABB could also help I don't know. I wonder how current engines calculate center point for model and for scene. AABB is changing after transform so center point of two AABB is also changing.
  9. Hello, How can I get center of scene or node or model? What is best way to do this? Scene structure: Scene | o - Node[s] | o - Model[s] // Mesh | o - Primitive[s] // Sub-Mesh | o local AABB and world AABB I'm using AABB's center as center of primitive and I'm combining all AABB boxes to build an AABB for scene. When I visualized the boxes it seems work as expected. But I need to get center of scene, node or model for apply rotation around center. Because I'm using a trackball for rotating attached node or model. Currently I'm using scene's AABB's center as rotation point (pivot), for single object it is working. After rotation is completed center of primitive remains same which it should be, I think. But if I load a scene which contains multiple models or primitives, after rotation is completed center of scene's AABB is moving (I'm using that as center of scene). Because every time rotation is completed, new AABB is calculated for scene by combining all sub AABB boxes. I think this may be a normal because there is no balance between AABB boxes while rotating. For instance if I use two same CUBE without rotations center of new scene's AABB remains same. My solution (it seems work for now): I created new center member (vec3) in scene struct: scene->center = vec3(0); scene->primCount = 0; for prim in primitivesInFrustum scene->center += prim->aabb->center; scene->primCount++; scene->center = scene->center / scene->primCount Now I'm using this center as center of scene instead of scene->aabb->center and it seems work. My question is that what is best way to get center of scene, node or model? How do you get the center for rotation? Any suggestions? Am I doing right? Thanks
  10. recp

    Euler Angles To Matrix

    EDIT: It seems Wikipedia version also correct, it is all about different naming conventions. For Z1 X2 Y3 rotation I think c2c3 means cxcy, it seems like they used order index here: now everything is clear.
  11. recp

    Euler Angles To Matrix

    I tested all orders (XYZ, XZY, YZX, YXZ, ZXY, ZYX) with wolframalpha tool it seems PDF version is correct, XZY matrix: http://www.wolframalpha.com/input/?i=[[1,0,0],[0,cos(x),-sin(x)],[0,sin(x),cos(x)]]*[[cos(z),+-sin(z),0],[sin(z),cos(z),0],[0,0,1]]*[[cos(y),0,sin(y)],[0,1,0],[-sin(y),0,cos(y)]] As I mentioned in first post, some matrix components seem different on Wikipedia. FWIW, my implementation can be found at: https://github.com/recp/cglm
  12. recp

    Euler Angles To Matrix

    @alvaro thanks for sharing it, I'll check it asap. Also I found this: https://en.wikipedia.org/wiki/Rotation_matrix (General rotations) I'm not sure reversing the order like RzRyRx to RxRyRz will give reverse intrinsics rotation (ZYX -> XYZ) I will try this multiplication with wolframalpha tool and compare result matrices with wiki and that reference PDF
  13. I want to implement XYZ, XZY, YXZ, YZX, ZXY, ZYX intrinsic Tait-Bryan rotations to matrix (Right Hand), So I implemented formulas in this PDF: https://www.geometrictools.com/Documentation/EulerAngles.pdf The problem is that some formulas (or components) appears to be different in wikipedia: https://en.wikipedia.org/wiki/Euler_angles See the "Rotation matrix" section and XZY order. XYZ seems same. Wikipedia version used s1s3 + c1c3s2 but the PDF used sxsy + cxcysz for m01, −s2 in wiki −sz in PDF for m10... I'm confused Does anyone know which one is correct? Thanks
  14. It seems this is most reasonable thing to do, thanks for your feedback.
  15. It could save me to create another framebuff for opaque objects, since I render opaque objects to default frame buffer I need to default depth buffer for second pass. There are three passes (see page): 3D opaque surfaces to a primary framebuffer 3D transparency accumulation to an off-screen framebuffer 2D compositing transparency over the primary framebuffer ( using alpha blending ) For transparency pass it says "Test against the depth buffer, but do not write to it or clear it.". So it seems I don't need to write depth buffer in transparency pass, I only need to read opaque's one to test depth which is default depth buffer. Binding default depth buffer ( after opaque pass ) to transparency framebuffer would be nice but I'm not sure if it is possible or not. As alternative I created a depth buffer for off-screen framebuffer (transparency) which is GL_DEPTH_COMPONENT24, it seems glBlitFramebuffer offer copying a buffer to another frame buffer. But what if formats mismatch? 32-bit vs 24-bit Another alternative is that creating a framebuffer for opaque surfaces too. Then since I have depth buffer ID, I can bind it to another framebuffer I guess, then set depth mask to false. But I need to create another color buffer / color attachment and depth buffer for this framebuffer. I don't know which one is faster copying default depth using glBlitFramebuffer or this method.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!