3000th commit - IrrlichtBAW (GIT repo, v 0.3.0-gamma1)

[hendu]

Thanks for using git instead of mega.

6) remove all s8,u8,s16,u16,s32,u32,s64,u64 and f32 and replace with float and types from stdint.h

Why? That's pointless code churn and just increases the diff for no reason. I could understand removing the logic in irrTypes and making the types just typedefs for the longer stdint ones.

Personally, I find u8 a lot more beautiful than uint8_t, and a lot less typing too, but that's just an opinion.

[devsh]

Because we use stdint everywhere and its a weird mix

[devsh]

1) Made backport to EXT_dsa and slow workarounds for Non-DSA GPU drivers

2) Implemented this nifty thing ---> GPU Pinned MALLOC
https://developer.nvidia.com/sites/defa ... Donald.pdf

3) Fixed 50% of the MeshManipulator:
a) Made flipPolygons which works on EPT_TRIANGLE_STRIP and EPT_TRIANGLE_FAN meshbuffers



Will commit to GIT... maybe on friday

Things left to do:
1) Remove unnecessary dynamic_casts
2) Make use of IGPUAnimatedMesh compulsory (Hardware Skinning)
3) Fix all 4 mesh writers (only STL works for now)
4) Test Drive with BaW
5) remove all s8,u8,s16,u16,s32,u32,s64,u64 and f32 and replace with float and types from stdint.h

[devsh]

New GIT commit!

IGPUTransientBuffer encapsulates IGPUMappedBuffer and gives you allocations of subranges which can be written to by CPU and seen by the GPU immediately with fences for synchronisation... works just like malloc() and free() but of GPU memory

*just missing a getPointer() method, and some testing

[devsh]

Integrating into BaW, expect a 0.1 release in a week!

[Locien]

Cool stuff. Many thanks for doing this

By the way, the VS project in the latest git commit doesn't compile because there are a ton of I assume intentionally removed source files that are still listed in the project. Did you mean to do away with Irrlicht's native GUI?

[devsh]

yes I did mean to AXE the GUI

We have a VS 2016 project that works, so it will be committed

we're still holding out on 0.1 release because we needed to fix the .X Mesh Loader to spit out static non animated meshes if the file had no bones nor animation frames.
Also the TransientBuffer needs a redesign of the wait flag into a bitfield, because one needs to be able to wait for the CPUs without waiting for the GPU etc. as well as being able to specify the allocation alignment relative to buffer start (to be able to set Buffer offsets as BaseVertex which are a much easier than setting the offset in the VAO for every reallocation -- and enables the use of shared VAOs for multiple meshbuffers)

And now TransientBuffer can encapsulate both a Mapped and a pure GPU buffer (because why not, you might have to allocate chunks out of a GPU buffer for copying Mapped GPU buffers into it!)

But as an extra we implemented Hardware Instancing, and made an example of how to use it

[devsh]

XMeshLoader has been fixed and TransientBuffer gives nice aligned memory locations now*

*Aligned with relation to the buffer start point, not an actual aligned memory address!!!


We stressed the TransientBuffer and we've found the alloc to be quite slow with a fragmented buffer, so some optimizations will be in order:
1) Keeping track of a index of a plausibly free chunk (do we keep the index to the largest chunk, or the nearest to the start to avoid buffer fragmentation??, or do we keep a whole list of indices sorted by the chunk sizes??)
2) Avoid spinning on checking GPU fences when also waiting for CPU Free()s (only spin when unfencing can actually give us a continuous chunk of unallocated and unfenced memory large enough)
3) Allow the resize of buffer while fenced by GPUs (since resize will take place from and synchronously with the render thread) {Only CPUs need to finish with buffer before resize}

[devsh]

We've been taking a bit of a long time, since we suddenly found ourselves instancing for no reason

As an added freebie we now have SSE3 quaternion class, used by default inside irrlicht, so all skinning is accelerated by SSE3
*Also extended the quaternion class to handle isotropic scaling AND rotation (since if it has 4 independent floats, it must allow for 3D rot plus 1D scale)

[devsh]

Features are snowballing, in order to preserve OpenGL 3.3 core compliance and not mess around with our VRAM buffers, we introduce Transform Feedback (which we will use for cutting and pasting mesh data).

[devsh]

Turns out that to use openGL fences across threads you need to initialize shared contexts...

So BAW Irrlicht is getting those too, multithreaded OpenGL (yay)!!!

[devsh]

Added an SSE3 optimized SCollisionEngine basic class which is separate from main Irrlicht and fully inlined (header only) for doing ray-{triangle,box,ellipsoid,triangle mesh} intersections
Also added an SSE3 optimized quaternion class

Stuff to do for the 0.1 Release:
1) Remove unnecessary dynamic_casts
2) Test thoroughly with Intel and AMD
3) Implement Transform Feedback

For the 0.2 Release:
1) Make use of IGPUAnimatedMesh compulsory (Hardware Skinning)
2) SSE3 SIMD Dual Quaternion Class
3) Dual Quaternion Skinning
4) InstancedMeshSceneNode for static and animated nodes!
5) remove all s8,u8,s16,u16,s32,u32,s64,u64 and f32 and replace with float and types from stdint.h

[Vectrotek]

This looks interesting. Keep up the good work!

[devsh]

I can confirm we have problems on Intel and Radeon GPUs, working hard to resolve them.

[thanhle]

I'm keeping an eye on this.
----------------------------------
I was looking at Urho3D for a little while. It has nice performance with shadows. The animation code is more optimised and bullet physics binding is quite fast. You could have 1000s of box colliding without performance hiccup. But I think it has some drawbacks as well. Urho3D seems to update regularly e.g. 1 or 2x a year.
------------------After working with Urho3D for a project I still want to go back on Irrlicht. But Irrlicht engine is kind of out of date.

Anyway on your Irrlicht version. Since you are adding Quaternion to animation, you might want to add matrix to quaternion conversion or vice versa.
Some people like me do like using both transformation matrix as well as Quaternion for animation.

By the way do you plan to have transformation using pure Quaternion or Transformation matrix rather than angle? Or make the rotate function automatically convert to transformation matrix and compute the final transformation matrix rather than adding angle and compute the matrix.

Oh, can't wait for multi threading.

I think Irrlicht need to update more regularly. Maybe move to Git Hub and have a more flexible way for contribution, let more people involve. At the moment it is too much work for two people.

I think it is better to have new features and iron out the bug as you go.

Cheers