Quote:Original post by BaSSraf
http://www.ez-xpert.com/samples.html

See link and look for supplemental dll's

thanks. Let's hope it'll work.

I probably found a problem - i placed call to important code into assert [grin] and without that code my edge data structure(where i store resuls of tesselation) becomes inconsistant...

first executable(one without motion blur) has been fix0r3d.
(i compiled it in release mode)

Probably should work.... if will not work w/o dlls , inform me, becoz it's really important for me to know if my programs work everywhere.

Quote:Original post by Charles B
Yep. Known issue. ;) In all my projects I use a root header files with some useful common stuff like endianness, standardization of compiler dependent keywords (ex: alignment), etc... I also always have a custom assert() (ex: xAssert) for all my libs. I can do whatever I want, int 3 (enter debugger), log to file, collect stats, etc...

And I have this option : xKEEP_ASSERTS. Very useful !

i'm doing something like that... most of my projects include "utilsandhacks.h" where compiler-dependant thingies is placed. e.g. ifdef min undef min
if(MSVC_VERSION is stupid)
namespace std{
templated min and max
}
, etc.
i just defined my_assert that trows runtime_error. (btw, in C++,unhandled exception it's crash,right?)
more on topic... does it work now?
Also, browsers may cache this file, so i added "?nocache=12345" to url in link .....

btw, i think there just _will_ be problems if you'll try to simulate u2 drag in water with Euler integrator.(at least RK2 is necessary, RK4 will work even better) So it's why this prog have drag proportional to velocity, not velocity squared...

i've played a bit more with that code... i can say, it's awfully stable. It works even at 3 steps per second and box_density=0.05 (the smaller density is, the less it stable... say, with density of 0.02 it's not stable at 3 steps per second(box just chaotically jump up and down a bit, but nothing really bad happen)).

I can't believe you got that up and running so quick? It looks fantastic by the way, the moment is excellent! Will it work fine if the water surface is moving up and down??? I guess it will.

Quote:Original post by Hybrid
I can't believe you got that up and running so quick? It looks fantastic by the way, the moment is excellent! Will it work fine if the water surface is moving up and down??? I guess it will.

[smile]
It was simply matter of putting equations. It haven't needed any tuning - i selected k=1.5 since the beginning, etc (the only thing i tuned a bit is that restarting code, took less than typing typical long message in English).

Sure. One important point:
you need to do
f-=dh_dt*friction;
and
dh_dt*=min(1.0,prev_em/em);
relatively to water.

That is,
....
double rel_dh_dt=dh_dt-water_dh_dt;
.....
f-=rel_dh_dt*friction;
.....
rel_dh_dt*=min(1.0,prev_em/em);
....
dh_dt=rel_dh_dt+water_dh_dt;

Also to absolutely ultimately increase stability, instead of
f-=rel_dh_dt*friction; // drag force
you can do
rel_dh_dt*=exp(-game_dt*friction/em); // analitical drag results for given timestep
And it probably will work well with densities down to 1E-4 (hydrogen) The only reason it fail to work with extremely small density is that drag.

BTW, friction should depend to type of object, should be roundly proportional to it's cross-section.

BTW2, it looks the best from bottom side of water cube, from where you can see all events( start and impact)...

BTW3, once it'll work you can try to play with drag force direction.

BTW4, you can actually compute your underwater volume, it's very similar to computing volume of arbitrary objects.(say, if you use piramids method, you must just compute underwater volumes of piramids only. If you use prisms method , similarly)