3 ms·

The rendering engineers on Cyberpunk are definitely career experts. But, hobbyists can get impressive results in their spare time. IMHO, a good target to shoo

The rendering engineers on Cyberpunk are definitely career experts. But, hobbyists can get impressive results in their spare time. IMHO, a good target to shoot for is to write your own https://www.khronos.org/gltf/ https://www.khronos.org/gltf/ viewer. It's a scalable goal that you can take as far as you like. Start with https://github.com/jkuhlmann/cgltf https://github.com/jkuhlmann/cgltf to handle loading the data. Check the sidebar of https://www.reddit.com/r/opengl/ https://www.reddit.com/r/opengl/ for tutorials.

atum47 6y ago
thanks. I was able to get the basics stuff out of the way: https://victorribeiro.com/3Dsphere/ https://victorribeiro.com/3Dsphere/ https://www.youtube.com/watch?v=w13Q_KL1I9A https://www.youtube.com/watch?v=w13Q_KL1I9A I just need to focus a little bit more in order to get more complex stuff done. for instance: I don't know jack about animations / bones / skin deformation. =(
- ilays 6y ago
  https://www.amazon.com/Real-Time-Rendering-Fourth-Tomas-Akenine-M%C3%B6ller/dp/1138627003 https://www.amazon.com/Real-Time-Rendering-Fourth-Tomas-Aken... try this if you have time
  - corysama 6y ago
    That book is a highly-recommended intro. The site for the book https://www.realtimerendering.com/ https://www.realtimerendering.com/ also list tons more great material.
- brundolf 6y ago
  > I don't know jack about animations / bones / skin deformation I only know the basics, but as far as I know that stuff is generally pretty straightforward (at least compared to actual rendering) Basically you have an invisible vertex floating inside the mesh, and vertices on the visible mesh are "weighted" to it (with a floating point weight), so that when the bone moves, it "pulls" vertices towards it based on the weight strength. A mesh vertex can be weighted to multiple bone vertices at once. Bones typically consist of two vertices, where one is treated as an anchor and the other rotates around it. They're then arranged in a hierarchy, so that a parent bone's transform (translate/rotate/scale) applies to its children, and so on. So for example, rotating an upper arm bone causes the forearm bone to rotate with it. An animation is then a series of keyframes on those bones (translate/rotate/scale to a particular x/y/z at time t). Those keyframes are interpolated when the animation is applied, and the mesh vertices are dragged along accordingly. Motion-capture is just taking position data from a live actor and mapping it to those bone keyframes. Things get slightly more complicated when it comes to blending between multiple animations (for example, running + swinging a sword; you basically average the keyframes). And then there's IK or Inverse Kinematics, which basically means that instead of driving an animation purely from explicit keyframes, you procedurally place the "end" of the limb (a character's foot goes all the way to the ground, for example) and then procedurally work backwards adjusting the bones up the hierarchy to satisfy that position. This is pretty common these days and leads to dramatically more natural-looking animation for characters and creatures (you can see it in action by walking on some stairs in a recent game). I don't know exactly how it's implemented. But that's about it from a technical perspective. Of course the artistry of getting all of this just right is much harder - from the bone-weighting ("rigging") to the keyframes to the motion capture data cleanup - but the technical aspect isn't nearly as complicated as rendering (to my understanding).
  - atum47 6y ago
    I get the concept because I used to be a 3d artist... But when it comes to program this... A static model I just copy it's vertex position to a buffer, right? So when there's a bone animation I just update the vertex in my models and the copy it again to the buffer, for every frame?
    - 936936 6y ago
      Your vertex buffer should hold indices for which bones influence the position of each vertex and by what fraction. Each vertex could, for example, have 4 indices and 4 floats to indicate these values, and these only need to be uploaded to the gpu once. The transformation matrices are interpolated for each rendered frame using the hierarchial animation data and the computed matrices are uploaded to the gpu in a buffer. The matrices are accessed in the vertex shader by indexing into the matrix buffer to calculate the vertex position.
    - brundolf 6y ago
      Ah, I misunderstood. Yeah I've never actually implemented it myself :)
    - corysama 6y ago
      That can work. But, it's slow. The way this has been done is to not modify the buffers and instead do the work in the vertex shader. The vertex shader sends the skinned verts straight to the triangle rasterizer and then then are never needed again. So, no need to read-modify-write the buffer just to have the rasterizer read it back again.
      - atum47 6y ago
        yeah, I figured that should be a better solution. I was using ThinMatrix [1] videos as guidelines when I was creating my engine. I'll take a look in how he implemented animations. Thank you. 1 - https://www.youtube.com/user/ThinMatrix https://www.youtube.com/user/ThinMatrix
    - BearOso 6y ago

atum47 6y ago

thanks. I was able to get the basics stuff out of the way: https://victorribeiro.com/3Dsphere/ https://victorribeiro.com/3Dsphere/ https://www.youtube.com/watch?v=w13Q_KL1I9A https://www.youtube.com/watch?v=w13Q_KL1I9A I just need to focus a little bit more in order to get more complex stuff done. for instance: I don't know jack about animations / bones / skin deformation. =(

ilays 6y ago
https://www.amazon.com/Real-Time-Rendering-Fourth-Tomas-Akenine-M%C3%B6ller/dp/1138627003 https://www.amazon.com/Real-Time-Rendering-Fourth-Tomas-Aken... try this if you have time
- corysama 6y ago
  That book is a highly-recommended intro. The site for the book https://www.realtimerendering.com/ https://www.realtimerendering.com/ also list tons more great material.
brundolf 6y ago
> I don't know jack about animations / bones / skin deformation I only know the basics, but as far as I know that stuff is generally pretty straightforward (at least compared to actual rendering) Basically you have an invisible vertex floating inside the mesh, and vertices on the visible mesh are "weighted" to it (with a floating point weight), so that when the bone moves, it "pulls" vertices towards it based on the weight strength. A mesh vertex can be weighted to multiple bone vertices at once. Bones typically consist of two vertices, where one is treated as an anchor and the other rotates around it. They're then arranged in a hierarchy, so that a parent bone's transform (translate/rotate/scale) applies to its children, and so on. So for example, rotating an upper arm bone causes the forearm bone to rotate with it. An animation is then a series of keyframes on those bones (translate/rotate/scale to a particular x/y/z at time t). Those keyframes are interpolated when the animation is applied, and the mesh vertices are dragged along accordingly. Motion-capture is just taking position data from a live actor and mapping it to those bone keyframes. Things get slightly more complicated when it comes to blending between multiple animations (for example, running + swinging a sword; you basically average the keyframes). And then there's IK or Inverse Kinematics, which basically means that instead of driving an animation purely from explicit keyframes, you procedurally place the "end" of the limb (a character's foot goes all the way to the ground, for example) and then procedurally work backwards adjusting the bones up the hierarchy to satisfy that position. This is pretty common these days and leads to dramatically more natural-looking animation for characters and creatures (you can see it in action by walking on some stairs in a recent game). I don't know exactly how it's implemented. But that's about it from a technical perspective. Of course the artistry of getting all of this just right is much harder - from the bone-weighting ("rigging") to the keyframes to the motion capture data cleanup - but the technical aspect isn't nearly as complicated as rendering (to my understanding).
- atum47 6y ago
  I get the concept because I used to be a 3d artist... But when it comes to program this... A static model I just copy it's vertex position to a buffer, right? So when there's a bone animation I just update the vertex in my models and the copy it again to the buffer, for every frame?
  - 936936 6y ago
    Your vertex buffer should hold indices for which bones influence the position of each vertex and by what fraction. Each vertex could, for example, have 4 indices and 4 floats to indicate these values, and these only need to be uploaded to the gpu once. The transformation matrices are interpolated for each rendered frame using the hierarchial animation data and the computed matrices are uploaded to the gpu in a buffer. The matrices are accessed in the vertex shader by indexing into the matrix buffer to calculate the vertex position.
  - brundolf 6y ago
    Ah, I misunderstood. Yeah I've never actually implemented it myself :)
  - corysama 6y ago
    That can work. But, it's slow. The way this has been done is to not modify the buffers and instead do the work in the vertex shader. The vertex shader sends the skinned verts straight to the triangle rasterizer and then then are never needed again. So, no need to read-modify-write the buffer just to have the rasterizer read it back again.
    - atum47 6y ago
      yeah, I figured that should be a better solution. I was using ThinMatrix [1] videos as guidelines when I was creating my engine. I'll take a look in how he implemented animations. Thank you. 1 - https://www.youtube.com/user/ThinMatrix https://www.youtube.com/user/ThinMatrix
  - BearOso 6y ago