search

pranavsureshpn / gpusphsim

Automatically exported from code.google.com/p/gpusphsim
0 stars 0 forks source link

Sometimes OgreSimRenderable::mVertexBufferPosition contains NAN data. #6

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago 
I've tried to take a look at this but the current svn code does not seem to 
compile.
It seems like the metaballs3d project does not use any kind of namespace and 
thus conflicts with CUDA (uint typedefs collide).

Truth be told I doubt the current SPH algorithm/configuration parameters will 
work work at all with only 3 particles.
I have not really tried using that few particles at all since my work was 
focused on using many particles.
Have you tried more?, you'd probably want atleast a few thousand for stability.

I fear however that metaballs are a very poor choice for surface reconstruction 
for SPH simply because it's very slow with many particles.
I think that for there to be any point in surface reconstruction it must be 
done on the GPU, just as the SPH calculations are.

In my opinion there are two immediate possibilities that could be easily added:
1. GPU metaballs (the CUDA samples have metaballs code I think, so it should be 
fairly easy to add). This might get you fairly realtime simulation with a few 
thousand particles.
2. Screen-space surface rendering/approximiation.
Take a look at this: 
http://developer.download.nvidia.com/presentations/2010/gdc/Direct3D_Effects.pdf
It's a fast screen-space surface-rendering technique that is pretty much ideal 
for SPH.

Øystein

Original issue reported on code.google.com by yaoya...@gmail.com on 21 Jul 2011 at 6:26

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Hmm, I just tried an older version of the code and it does in fact "work" with 
as few as 1-10 particles, it does not seem like they turn into NaN.
If you fix the compile errors I'll try to reproduce and look into it with the 
latest code as well.

On possibility also:
I see that you use HBL_READ_ONLY to lock/read from the hardware buffer.
The simulation rendering buffer is created with HBU_DISCARDABLE (in 
OgreSimRenderable.cpp), which is "Combination of HBU_STATIC and HBU_WRITE_ONLY".
HBU_READ_ONLY documentation says:
"Lock the buffer for reading only. 
Not allowed in buffers which are created with HBU_WRITE_ONLY. Mandatory on 
static buffers, i.e. those created without the HBU_DYNAMIC flag."
The reason I create the rendering buffers as HBU_DISCARDABLE is for maximum 
speed. Try to change this to HBU_DYNAMIC, which should makes it possible to 
read back into system memory (this does however come with a performance penalty 
since GPU-CPU transfers are fairly expensive).

Øystein

Original comment by oystein....@gmail.com on 21 Jul 2011 at 4:11

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
Ok, good that you found a temporary workaround. I'll take a look again as soon 
as I can. I'm on vacation right now so I don't have access to a develoment pc.
Also I'm excited that you are working on integration of GPU-based metaballs:)

Original comment by oystein....@gmail.com on 23 Jul 2011 at 1:51