Problem with static mesh collision in core 300

[Julio Jerez]

one thing you coudl do to help me. is to send me the ngd file that make the simd path fail for debuggin.
I can use it to fix the pices than are malfuntions until we get to the OpenCL implemenation.

do you think you can send me that file? I ask because if was simpel and can be used to debug the problem.

[Bird]

one thing you coudl do to help me. is to send me the ngd file that make the simd path fail for debuggin.
I can use it to fix the pices than are malfuntions until we get to the OpenCL implemenation.

do you think you can send me that file? I ask because if was simpel and can be used to debug the problem.

Sure. its here: http://www.hurleyworks.com/downloads/static_mesh_problem.zip

When the scene loads into the SDK viewer the objects are out of view and you'll have to rotate the camera to the left to find them.
If you need any more simple examples that fail, I'll be happy to try to create some more.

-Bird

[Bird]

If you already downloaded the file please download again ... the first one I uploaded wasn't the right one.

-Bird

[Julio Jerez]

exccelent,

The file format support up to for Cameras, but I am not using it now.

for now I will make an anjustment so that is focus the camera to the center o fteh scene if the file does not have one.
but in the future I will also save add a place in teh contxt so that teh user save teh prper Camera settings.

[Julio Jerez]

thsi is the fist time I start to feel like my invesment on teh file format will pay off.

I place lot of effort on that, and no one seems to care about.
First I want to embrace collada, but collada despite being ultar huge, is such a poor implemention of a assete manager that I decise to go with my own.


Basically the ideal of teh format is to provide suppot for physics effect, is soport grapich because soem of eth epcial effect that I are on the pipe line
Destrustion, SoftBody, Cloth, are not just physics effet they are a combination of both.
I do not kwo if you fallow but I have some of teh profee of conspet fo rmany of thoso (with teh excmtion of cloth wich I will leave for afte a Polish what I have now in core 300)


But it is not just that sone effect liek Vehicle controller, Player controller are diffcult for the regular user to implemnet so ther teh format come to the rescue too.
bascially I can save a Tempale of a Vehicle and and end user cal load it, and by simple replacing teh Graphics Node on teh context, he can have that Vehicle in his code.
and form his point of view it will be adding a Game Play script to controll teh effect, similar for the other effects.

[Bird]

thsi is the fist time I start to feel like my invesment on teh file format will pay off.

That's good to hear. I haven't had the time to really understand how it works but like the rest of Newton it seems really well done and you've certainly made easy for us to save a ngd file from our application.

Basically the ideal of teh format is to provide suppot for physics effect, is soport grapich because soem of eth epcial effect that I are on the pipe line
Destrustion, SoftBody, Cloth, are not just physics effet they are a combination of both
I do not kwo if you fallow but I have some of teh profee of conspet fo rmany of thoso (with teh excmtion of cloth wich I will leave for afte a Polish what I have now in core 300

Yes, I've been watching them closely ... I'm really really interested in having those features in my project.
I made a fracture demo with Newton a few days ago. http://www.hurleyworks.com/media/flash/Busted/Busted.html
I had problems with Newton Boolean Intersect so I had to use another library to generate the fracture pieces but I hope someday to do it all in Newton.

and form his point of view it will be adding a Game Play script to controll teh effect, similar for the other effects.

Is that's what dCompilerKit is for? I've been wondering about that.

-Bird

[Julio Jerez]

hey that is very cool, what library you used. is that a voronoi or bolleans?
after I complet teh car demo I will go back to put to the teh Voronoi demo whis is unfinish, I needded teh combe decomposition to sobdicve complicate dmeshe in cluste of siples faces, no wI think I have all the elements.


the dCompilerKit is a toll for making script, and graphics design. it is a long turn project.
bascally with tah tool, my goal is to have a dCript with si almost compled, it is a object oriened scrip languge simila to jave or c#

anoither thing in teh file format is that I am pallyin to make a joint parcel, right now cutom join are flexible, however thet are dificult to export.
wha this till will do is that it wil read teh joint code and export the joibnt configuration so ta if cna be reagrated, similar to what a shader does.

ther are tons of app for the for the parcel generator and lexical analizer.

[Bird]

hey that is very cool, what library you used. is that a voronoi or bolleans?
after I complet teh car demo I will go back to put to the teh Voronoi demo whis is unfinish, I needded teh combe decomposition to sobdicve complicate dmeshe in cluste of siples faces, no wI think I have all the elements.

I used Voro++ to populate the mesh's bounding box volume with voronoi cells and then send each cell to my thread pool where the boolean interesections that create the fractured pieces are performed in parallel so it is extremely fast. For the demo I used Carve for the csg but it is the wrong license for my project and the author does not respond to email inquires so I will not be able to use it for my shipping product. So I'm hoping I can do it all Newton.

the dCompilerKit is a toll for making script, and graphics design. it is a long turn project.
bascally with tah tool, my goal is to have a dCript with si almost compled, it is a object oriened scrip languge simila to jave or c#

Sounds cool. You are amazingly prolific.

-Bird

[Julio Jerez]

Ok I think I fixed the simd bug. in core 300.
I also added the VS2010 projects.

The strutioe in teh engien is all mesx up still because VS2010 is buggy and do not recover projects from VS 2008 very well.
but for teh project is working.

Tnak for the test, It helped me a lot in tracking that Bug

[Bird]

Tnak for the test, It helped me a lot in tracking that Bug

I'm glad I could help. I only have access to a Mac for a couple of weeks so I can't do any testing, but I'll check it out as soon as I'm back in the windows world.

-Bird

[Julio Jerez]

I was reading about OpenCL, and again I am quite disappointed.
OpenCL is as moronic today as it was when it was proposed.
What was I thinking from the Khronos Group, as if the will somehow will make some useful for a change.

about three years ago I was reading about OpenCL and try to use it and I decided to wait until It gets better, but it has not changed, it is a bad as CUDA was at the time.
This is the big problem I have with both CUDA and OpenCL.

they are designed to use Kernels call that utilize the entire Hardware on single kernels, what this mean is the you have to write your code with extreme severe restrictions.
almost as if is was a Pixel shader or a vertex shader where the asumption is that you will have thousands of equal operations but with different data.
In physics this is never the case. you could arrange your data to work like that but the payoff for that is huge memory foot print for some marginal performance gain.
The net result is that you end up with two or more version of the same function. and a nighmare inb maintanace and extension.

An example of what I mean is a collision system. A collision system will have different primitives types. The calculation of contact is the most expensive part not the high level queries.
CUDA and Open CL can easy handle the high level queries because they made of similar operations.
whne you need to calculate collision for each pair of shape that result from the high level queries. this is where they go bunker.
it is unlike you can write a kernel that can resolve even the simplest pair like a sphere and a box in one call, no to mnetion that you
have sevral diffrent time of pemutaion pairs (sphere sphere, sphere convex, shere triangle, and so on) .
each subbacth wih mutple kernels call. so you end up writing several dozent if no several hundred for those kernels and the net result is that must of then each call will not have enough data to process.
This is a common problem that Graphic programmers face when deciding how to render data, they spend over 95% of the time deciding how to batch
data together so that each render call have the maximum number of similar operations.
The same happen for physics but physics calculation are more than an order of magnitud more complex that pixel shaders,
therefore the combinatorial explosion of Shader (they call it kernel in CUDA and OpencL) is much more severe, and I will not do that.
However came up with that hardware architecture and thought that the was good must be a complete moron.

When Intel decided to implement OpenCL my guess was that they will make so that the user can use the Cores independent from each other,
That way you could dispatch different task to different core in the same loop, Apparently Intel is working on a extension to Opencl that the user to brake the hardware into logical devices,
however this is a Band-Aid that do not really solve the problem, beside is is no ready and it is not supported but any vendor.
The bottom line is that OpenCL is not really a solution for High performance computing.

What I am going to do is that I will use AVX directly, the same way I am using SSE.
I already set up the Visual studio 2010 projects, and I am adding the support for it now.

some of the feature that I am working (Cloth, soft deformable, debrie, particles) will diffidently require some ways to massive high performance computing, but CUDA and Open CL are not the solution.
so AVX it is.

[d.l.i.w]

Am I right that AVX is quite new, so most of the CPUs don't support it?
http://en.wikipedia.org/wiki/Advanced_Vector_Extensions

Another thing about OpenCL:
If you look at other Physics Engines it seems that they work quite well with OpenCL / CUDA, e.g.

As I'm not an expert: Is this the problem you mentioned a general one, or is it possible to circumvent it by using an other data-structure or ... whatever??

What do you thing about this:
http://www.nvidia.com/content/GTC/documents/1077_GTC09.pdf

[Julio Jerez]

why should I look at that, I look up not down. Newton with one core, in x87 mode, runs faster, more acurate and more stable than Havok and Physx.
We also have a published mutithreaded witch makes the engine also much faster. and can handle loads of tousand bodies very eassy
The only thing those engine have over Newton is the GPU particle and pseudo soft bodyes. But when it comes to Physics simulation not one can match the acuracy, flexibily an dperformac package that newton offerer simultaneuslly.
there are not a physics engine out there tha can match this.
http://newtondynamics.com/forum/viewtopic.php?f=14&t=5260

The only thing that make those techonology viable is the money invested in publicity to convince game producers of not using technologis like Netwon.
As for the open source stuff, I do not look at plegiarised work, I can really read the orginal work public in reviewed papers and also add my own work.

In any case OpenCL on cpu is designed to work with Simd, and in all case and OpenCL kernel is much slower than the equivalent version using hand written Simd.
OpenCL may be better in a GPU both, my guess is that since we do not have a way to code the GPU with proceducal laguage we will never know if it is really faster because the
language, or simple because the number simple cores running in parallel.
you can test what IO say by writin an opn CL kernel of a dat a metri mutily, and mutiply million matrices, in one go,
using uning teh smaller possible kernel with. so that only one matrix is mutiply by each dthred.
do the same on any pentionm core with tow or 4 core, you will see that the CPU is abput 4 to 10 tiem faster than teh GPU.
to make the GPU faster you will have to rearange the Matrix in strcture of array and grupo then so that one array of core in teh GPU operea at least on 32, 64 of 128 matrces at a time.
I have done that work, I even have a version of Newton than do run in CUDA, and I can tell you the extra ampunt of work is no worth the payoff in return.

[d.l.i.w]

Ok, that sounds plausible...

But concerning the speed CPU <-> GPU you have to admit that on high end computers GPUs are a lot faster than any CPU, provided the task to compute is highly parallelizable.

[Julio Jerez]

That is actually no true. It is the other way around. CPU are and has always being faster than GPUs.
I know it sound outlandish but is is the absolute undisputable truth.

you has being influence by the effect that the Big money marketing, and the result of extreme simplicity that Graphics programming with shades kernels has shown.
This has lead to the dogma that GPU are faster than CPUs.
These are the facts.

1- Intel is the most advance research company in microprocessor and memory, GPU silicon is in general one or two generation behind CPU. the core clock of a GPU is about one those of the core clock of a CPU.
Cpu micro code design is a least an order of magnitude more complex that the core of a GPU,
CPU has to do stuff like out order execution, speculative branch prediction and cache prediction.
GPU do not do any of that, because the Parallel processing will not allow to do that. In fact all GPU that implement a limited set of branch prediction, what they do is than auto Serialize the data, entire branch.
if you run the same code than implement a shader or Kernel in a cpu and compare it to the same code runner on a GPU you will see any CPU will outperform the CPU by a factor of at least 2 or 3 to one.
What make the CPU faster is the number of parallel units, and the dedicated hardware for rasterization and Texture fetch and interpolation.


if you want to see the difference in performance between a CPU and a GPU execution code with a small amount of branch in the inner loop look at the bench mark of sorting.
you will find that when sorting array under few million element CPU alway beat GPUs,
it is no until you have array of integer over 15 millions, that the fasters GPU start to take the edge over any dual core CPU.
The reason for that is that the batches has to be that large so that they can be broken in sub element and somehow guarantee that all the simple units of the GPU will have work to do.
basically the GPU beat the CPU because and only because shear brute force.
and one of the only type of application that show that pattern of simple brute force computation is rendering pixel with shaders. what else has a need for sorting arrays 15 million integer of more?


here is an article that in some way validate what I am saying
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=1&ved=0CCYQFjAA&url=http%3A%2F%2Fsbel.wisc.edu%2FCourses%2FME964%2F2011%2FLiterature%2FLeeDebunkGPU2010.pdf&ei=tnUdT_3jL-74sQKP6dSvCw&usg=AFQjCNER_fkbOq0UY3MrpzETU1O0fdzi-Q&sig2=BmOcJvJEcZgN6-PRKrD6