Jump to content
  • Advertisement

Green_Baron

Member
  • Content Count

    177
  • Joined

  • Last visited

  • Days Won

    7

Everything posted by Green_Baron

  1. Well, software that just works will be found on Linux, but rather on Debian or Gentoo than Ubuntu or Mint. Too much bloatware and undocumented "free" software in the latter. And i just wouldn't run a graphical surface at all on a safety critical system. What for ? Also (to stay with the paraphrases of a sinking ship :-)), on such a system one might want to throw overboard the systemd and replace it with something more safe & sound, which pretty much excludes Ubuntu since, from what i have read, the integration is too strong. I admire your work, i wouldn't be able to do that or would die of old age over such a task. And, though i have not experienced the bad old days myself, i really think things (especially graphics drivers for Linux of the main vendors) have vastly improved in the past. I don't have AMD (yet), but an old intel HD 4400 in the notebook and GTX 660 and 970 in my pcs. The Notebook can "only" run OpenGL 4.5, but that's fine for me. Back in the day i would, as @_Silence_ said, install nvidia via the downloaded script, but now the drivers are in the repositories (418.74 for Debian) and thus seamlessly updated with the usual update cycle without manual interaction. It is, of course, a pity that the free nouveau driver is so bad, but if i am not mistaken that's mostly Nividias responsibility because they don't work together with the open source community. So those guys have to reverse engineer ... Am reading (and trying to understandπŸ€” ) "Real Time Rendering" by Akenine-MΓΆller et.al. I think it really is a very rewarding and aspirational goal to completely implement even a subset of these completely from scratch, without building on the fundament of available APIs and drivers. One can just accomplish so much more using these fundaments. "Standing on the shoulders" and all that πŸ™‚
  2. Rather recent drivers are in the repositories, if one allows non-free ...
  3. As a first step to generate height maps on my own i started incorporating the algorithms of libnoise (c) by Jason Bevins, under the LGPL v2.1 or higher. It has never been easier to get noisy. Mapping a texture to a sphere or near spherical body is trivial, But when it comes to 'Oumuamua shaped objects things get distorted: Surface normals computed in two different ways, geocentric vec3 centricSurfaceNormal( const vec3 pos ) { return normalize( pos ); } and geodetic vec3 geodeticSurfaceNormal( const vec3 pos ) { return normalize( pos * u_oneOverRadiiSquared ); } Normals combined vec3 normalG = geodeticSurfaceNormal( position ); vec3 normalC = centricSurfaceNormal( position ); vec3 normal = ( normalG + normalC ) / 2.0f; vec2 texCoord = computeTexCoord( normal ); and height values looked up from a spherical height map vec2 computeTexCoord( const vec3 normal ) { return vec2( atan( normal.y, normal.x ) * c_oneOverTwoPi + 0.5f, asin( normal.z ) * c_oneOverPi + 0.5f ); } and then float height = texture( s_texture, texCoord ).r * u_heightFactor; displacedPosition = position + ( normal * height ); Still, between the two methods, there are vast open plains, so to say, only the centre area and the east- and west-poles are noisy. I'll probably have to generate the height maps specifically for the assumed ellipsoidal shape of the bodies that will use it as clothing. And what about two- or multi-lobed objects ? πŸ€” Tricky terrain ahead ...
  4. Green_Baron

    Weird circular orbit problem

    Correct. ~43 arcseconds/century are on the expense of spacetime curvature.
  5. Green_Baron

    Weird circular orbit problem

    <smartass> And that's why its orbit precesses because of Schwarzschild spacetime ... </smartass> πŸ™‚
  6. I assume it is the Phong model (and its derivatives).
  7. Green_Baron

    Best choice of laptop for developer/casual gamer?

    Have a look at these (but they are in Germany): https://www.linux-onlineshop.de/en/Linux-Hardware/Linux-Notebooks/Mobile.tuxedo# For 1700,- you could get one really mighty thing. Gamer versions hang a little higher, but still in range. I own a super flat, super light long battery life version one. Nifty thing, matte display, aluminium brushed finish. And it comes completely without any software. Not.a.single.byte. Runs perfectly with Debian. Depending on which side of the pond you are it may not be worth the efforts ... idk.
  8. Green_Baron

    Centering a Ball on the Screen

    That's a different video than the one i reacted upon in my post. Is your problem solved ? Because it seems that it is the camera that stays in position in relation to the terrain and the ball moves around as the camera turns. I thought you wanted the camera moving around the ball. Seems i misunderstood ...
  9. Green_Baron

    Centering a Ball on the Screen

    For reference, code of a working orbiting camera. 1.) Initialize camera vectors on setup: m_target is the position of the ball, translated to for example 0/0/0 m_position is the initial camera position, set to for example m_target - vec3{0,0,5} glm::vec3 direction{ m_target - m_position }; m_distance = glm::length( m_target - m_position ); m_yaw = glm::degres( std::atan2( -direction.x, direction.z ) ); m_pitch = glm::degrees( std::atan2( direction.y, std::sqrt( ( direction.x * direction.x) + ( direction.y * direction.y ) ) ) ); I use degrees because intuitive and makes more sense on display. 2.) In your render loop, after having processed input: float yaw{ -glm::radians( m_yaw ) }; float pitch{ -glm::radians( m_pitch ) }; // Calculate the camera position on the sphere around the target m_position = glm::dvec3{ m_distance * std::sin( yaw ) * std::cos( pitch ), m_distance * std::sin( pitch ), -m_distance * std::cos( yaw ) * std::cos( pitch ) }; // Normalization not necessarily needed here. But later when buidling the frustum. m_front = glm::normalize( m_target - m_position ); // conversion to float because precision isn't needed here m_viewMatrix = glm::lookAt( glm::vec3{ m_position }, glm::vec3{ m_target }, m_up ); // Also re-calculate the right vector. Normalize for later use m_right = glm::normalize( glm::cross( m_front, m_up ) ); m_projectionViewMatrix = m_perspectiveProjectionMatrix * m_viewMatrix; Code for an orbiting camera. Projection matrix is only calculated when viewport or near/far planes change. If you want to change the distance for example with the mouse wheel, you must recalc it in the loop. You will want to use pitch and yaw from the ball, so that the camera is following it. Also, maybe you will want to limit camera movement to the y/z plane, which should be trivial now that you have read the linear algebra things πŸ˜‰ No guarantee ;-). Edit: looks like you have deleted the video and thus invalidated my post. The camera in the video was still freely turning and not locked to the ball.
  10. Green_Baron

    Atomic shared pointer

    I have little experience with std::shared_ptr, only use it in very view places, but any info interests me. First, my question would be what is the exact problem with Gnollrunner's opinion on shared_ptr ? I have seen quite a few "home brews" of shared or reference counted pointers and that not only in ancient code. It would be nice, for the less experienced among us πŸ˜‰ to know the reason, if it is technical. For my naive understanding the so called smart pointers are all about ownership, not about regulating access to their objects. It is application responsibility to ensure that no undefined behaviour happens, in this case to take care of possible race conditions, like one would do with any other object, except for the reference counter and object destruction, that's responsibility of the shared_ptr. Am i wrong ? Edit: but https://en.cppreference.com/w/cpp/memory/shared_ptr/atomic2
  11. Green_Baron

    Centering a Ball on the Screen

    ??? Element wise multiplication, results in a new vector. These are the very basics you must know, or any attempt to help you will fail. Sorry for being so blunt ... https://learnopengl.com/Getting-started/Transformations
  12. I am having difficulties with my imagination. Is it correct that a single, untessellated patch has the correct winding order all over its area ? Drawing normals can reveal that. If not, then the order of the indices comes into my mind (if you're drawing elements), otherwise the order of the vertices as they are listed in the array buffer. But if the switch happens in the tessellation stage, i would assume that there something gets out of order, but i need more info for a better guess ....
  13. Green_Baron

    How math is used in game development?

    Hmhm, it executes ... or not. Mine usuallly not on the first try ... πŸ€”
  14. Green_Baron

    Text rendering really slow

    The OpenGL SuperBible has an example of rendering quads and bitmaps, called "alienrain". The source is on github. Just for completeness, maybe it can be helpful .... πŸ™‚
  15. Green_Baron

    How math is used in game development?

    All examples use some "math" somewhere. Do you mean puzzle games ? (like e.g. "2048") More game than math :-) Or something more complex ? More math than game ... Or something in between ? Some more specifications are welcome ...
  16. Green_Baron

    Text rendering really slow

    I didn't mean you should avoid uniforms, just not use them as a substitute for VAOs, because it seems to me that is the case. Maybe my opinion differs here from @Shaarigan's ? glBufferSubData is the correct function to update a buffer object, whatever binding point it might be bound to. It can be used when the cost of reallocating buffer storage is too high. It may be the case though that a buffer update can stall the pipeline, in which case multiple buffer objects or mapping and updating of regions of a buffer may be the better solution. I also think that instancing may not be the right way for drawing text, because there are more modern and flexible techniques than drawing sprites or bitmaps. I found another link that describes some details. But i personally am content with the functionality imgui provides. I doubt i can do it faster.
  17. Green_Baron

    Non-uniform patch terrain tessellation

    Originally published here: https://www.tandfonline.com/doi/abs/10.1080/2151237X.2009.10129287 and github as well: https://github.com/fstrugar/CDLOD Yes. A node is just a bounding box. It does not contain any data. The data is in the heightmap. A node is only a few bytes. A position, min/max height (two vectors), a bounding box 4 pointers to its children and a lod level. There is still some unnecessary redundancy in it that i'll take care of later. For example a quad tree for 2048/2048 height map, 5 lod levels and 32/32 leaf node size has ~725kb. But one could build it with 3 or 8 levels and node sizes of 128 or 8. Whatever fits the needs. Larger than 4096/4096 takes a few (2-3) seconds to load the height map texture and build the tree and extract the node's bounding boxes (extract min/max heights per node is probably the most intensive work). I haven't yet implemented any concurrency in my little framework. Number of LOD levels, node size depend on the situation. I haven't played with more than 8 lod levels yet, because if the distances between levels in relation to camera depth of field gets too small for a clean gradual transition (morphing) between levels, cracks appear. In my tests, 3-6 levels and node sizes between 8 and 32 were good. External storage, for me is anything not RAM, a hard disk, a server, network storage. One can actually render a real world sized planet, that's my far goal. If you mean with patch a node of the quad tree, that's what the paper proposes ! But the world units can be and are different from the render resolution, if you mean that. One single mesh is sized and transformed and passed around for rendering each node. The node has (via its bounding box) world coordinates, but a configurable resolution. I have a blurry video of how that looks in my blog (someone must tell me how to configure OBS capture software to unblur it ;-)) that shows how the boxes and the terrain lod propagates as the camera moves. Your welcome. I am also well pretty new to all this, and would like to take it to rendering a planet 13 million meters diameter ... for some of you maybe something they did ten years ago ...
  18. Green_Baron

    Non-uniform patch terrain tessellation

    That is from F. Strugar's paper "Continuous Distance Dependent LOD". I (and others i am sure) have an implementation of that (C++/OpenGL), see my github. - peformance is not an issue. - level of detail and ranges as well as depths of transitions can be configured. - LODs are independent from tile sizes and quadtree resolution. Edit: no extra metric needed for transitions. - tile sizes can vary. I use square tiles for now cause it simplifies some things. Strugar's original uses non square tiles, but powers of two are convenient because quad-tree. - the quadtree is not built from the camera, it is built from the tiles and it is static during a tile's lifetime. - Otoh, the selection of nodes each frame is built from camera position (frustum culling) in world coords. - camera distance is the measure for selection, so the angle plays a role in the LODding. - size limit is (when streaming data) limited by the external storage media. - data footprint is extremely small, only a (16bit) heightmap is needed per tile. Everything else can be done in the shaders. Strugar uses normal maps, but i will do that in the shader, eventually with edge detection and all that. - only a single mesh the size of a node is needed. That makes it really fast, as only a small 2D vertex buffer of let's say 64/64 (the size of a leaf node * a multiplier) and its indices are needed. This is placed and scaled for every node to draw. I love that algorithm. It is so clean and straight πŸ™‚ Edit: the image does not show the whole quad tree of a tile (which is static and generated on loading), but the frame-based selection of nodes from that quadtree based on the camera position and view angle. I mention this to avoid eventual misunderstandings ...
  19. Green_Baron

    win32 breakout

    How to not draw a brick ... πŸ™„
  20. Green_Baron

    Text rendering really slow

    You are using opengl in a ... creative ... way it πŸ˜‰ by copying in large amounts of position and scale data as uniforms. Though that should not take 0.3 sec (if the data isn't copied in multiple times per frame, you haven't posted the code), it does not accelerate the process. Also, world matrix (which to my knowledge is just another word for model matrix) seems to be used for the view matrix. And, this is static 2D, a model matrix isn't needed, only position data and orthogonal projection (viewport size would suffice). I strongly recommend to play through the tutorials, and if interested read through the shader uniform and uniform buffer chapters. If there are large amounts of data that must be passed in as uniforms, one would create a uniform buffer and fill that with data, but that requires some more gymnastics (create a dynamic buffer, eventually map it, fill it with copying memory, and give it back to the driver). Keep in mind, the vertex shader is executed once per frame and per vertex, communication with the host program should stay low. In the case of character rendering, there is no need for uniforms at all, just position data from a vertex array object. Maybe text colour. Hope that wasn't too impertinent, it surely wasn't meant to be. A look at the vertex shader in the example linked above should clear up some thing. On my GTX 970 text rendering (with dear umgui) in a debug environment and compiled with full debug information the framerate is around 4.000-8.000/s. Edit: you wrote "do i have to craete a vao for every character". Nope, not necessarily, as the examples show. One could create a vao in any size. But reading data from a vao is much faster than from a uniform object and happens in parallel. One could maybe see a uniform more like an annoying interruption for the pipeline πŸ™‚
  21. Green_Baron

    Text rendering really slow

    Phew .. i am sorry, though i am a (small) C++ guy, i actually use imgui for all the ui stuff and text rendering, which relies on truetype. I haven't played with these tutorials (yet). Imgui, if it can be seen as a benchmark for that type of rendering, is very fast, i actually don't realise much of a difference in terms of framerate. If i understand it right from a short overfly, yes, in a loop they update and draw a dynamic vertex buffer per character. One can, of course prepare a larger buffer and draw that.
  22. Green_Baron

    Text rendering really slow

    This guy describes two techniques for text rendering.
  23. Green_Baron

    OpenGL, Translating a Sphere

    Who says they do ? They don't. They may have different model matrices, but the view- and perspective matrix are the same. @fleabay recommended to do everything in world coordinates (for now), to avoid having to switch around mentally between the coordinate systems. I kindly ask to doublecheck the tutorials for example on learnopengl.com, or the latest Red and Blue book on OpenGL. I hope a make no mistake now, this is the principle: 1. place objects in the world by applying rotation and transform to them. This is done with the model matrix for each object differently or grouped or whatever. One can place millions of objects this way. The model-transform puts the objects into world space. 2. calculate (in world coords) a camera position, view direction and up vector. The camera can perform any gymnastics one likes, using trigonometry, inverse matrices, offsets, or simply put into place. After the calculation of the camera position, view and up vectors, calculate the view matrix (glm::lookat()). 3. create the projection matrix from viewport size and near/far plane (glm::perspective()). 4. multiply proj and view and model matrix together to obtain all positions in camera space. The number of objects is banana, they are all just positions in world-space. This step is usually/frequently/partly done in a vertex shader. You are now pondering over point 2. How to calc the position of the camera. Hope that was not totally incorrect πŸ™‚
  24. Green_Baron

    OpenGL, Translating a Sphere

    The learnopengl.com tutorial has reasonable chapters on the spaces and transformations. You could begin with simply moving your camera with an offset from your model, like lookat( targetpos + offset, targetpos - ( targetpos + offset ), up ). So the camera will follow your object with the offset, looking at it. Now the problem is still, when the object turns, your camera will remain where it is, which is not what you want, you ant your cam to turn in the x/z plane (but not in y). Which makes it sort of a restricted orbiting cam. To follow turns you can either use what @soerensen3 suggested, or use trigonometry similar to the one you use for fp or orbiting cams. I leave it to you, it is really not magical πŸ˜‰
  25. Green_Baron

    Buoyancy problem for a boat

    They are a simplifications. A real ship gets overwhelmingly complicated quickly. To precisely calculate the forces in such a dynamic system one would at least need: - the shape of the hull and the construction waterline. - center of mass and center of lift to calculate righting moments from the static forces. Weight distribution and heel angle play a role here. - pressure point of the wind force, to calculate righting and turning moments induced from the sails. Easier for a for- and aft rigg (the typical sloop), but a tall ship like in the op is something much more complicated (basic Wikipedia article on wind forces). - other dynamic forces, resulting from movement of the whole thing in water and wind. These can be decisively strong when underway. Example: rudder and keel, drag and differences in displacement. My naive idea would be, if one wants it somewhat more realistic, to pre-calculate or -define polar curves for the moments and look up values for certain situations, interpolating between them. Don't ask me for detail, pls πŸ™‚ For a more simplistic model, how about (suggestion) just looking at the two centres of lift and mass. Assume the centre of mass is stable (or calculated when in harbour and after being loaded) and the centre of lift wanders around it depending on whatever dynamic aspects one needs. That way you only have a lever between the two centres and a resulting vector. You only have to take into account the righting force from the angle and the distance between the two centres. But you don't need the balls any more. Don't forget to model a dampening effect. Edit: btw. modelling flight is easier πŸ˜‰ I used the wrong terms. Pls. replace lift with displacement. I didn't mean aerodynamic lift on the sails, but the force that counters the weight of the boat immersed in water. Sorry for being incorrect. Still, the suggestion might be worth thinking over ... ?
  • Advertisement
Γ—

Important Information

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

GameDev.net isΒ your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!