From 69141db26d8545ae168dd63d19501fc2d51978b9 Mon Sep 17 00:00:00 2001 From: Aki Date: Fri, 1 Oct 2021 18:59:44 +0200 Subject: Removed Opcode Demo directory --- Opcode/Demo/Readme.txt | 142 ------------------------------------------------- 1 file changed, 142 deletions(-) delete mode 100644 Opcode/Demo/Readme.txt (limited to 'Opcode/Demo/Readme.txt') diff --git a/Opcode/Demo/Readme.txt b/Opcode/Demo/Readme.txt deleted file mode 100644 index d9e241a..0000000 --- a/Opcode/Demo/Readme.txt +++ /dev/null @@ -1,142 +0,0 @@ - - ====================================== - OPCODE (OPtimized COllision DEtection) - ====================================== - - Demo version 1.3b - - This demo compares RAPID 2.01 vs OPCODE 1.0. - - Information about RAPID can be found there: - http://www.cs.unc.edu/~geom/OBB/OBBT.html - - Information about OPCODE can be found there: - http://www.codercorner.com/Opcode.htm - - ----- - - I tried to be as fair as possible, and selected several scenes - where both RAPID and OPCODE show their forces. RAPID is usually - faster in close-proximity scenarii, especially when one object - is totally surrounded by another. OPCODE is usually faster when - objects deeply overlap. On my machine (Celeron 500Mhz), I have - found OPCODE to be faster overall. See for yourself. - - By the way, don't forget OPCODE's primary goal was *memory*, not - speed. Considering this, I'm quite pleased with the results! - - ----- - - Scenes have been exported with Flexporter: - http://www.codercorner.com/Flexporter.htm - - If you don't like them, you can export your own test scenes from - MAX - just ensure there are only 2 meshes in them. - - ----- - - How to proceed: - 1) Run Opcode.exe - 2) Drag&drop a ZCB file on the window - Messages such as "Chunk MOVE not found" are normal. - 3) Play! - - ----- - - OPCODE-related keys: - - 1 Toggle contact mode - - All contacts: report all colliding triangles - - First contact: report first contact only (a simple yes/no - answer to the overlap question) - - 2 Toggle BV-BV tests - - full tests: standard SAT (15 separating axes) - - no class III: SAT-lite (6 separating axes) - - 3 Toggle Prim-BV tests - - full tests: standard SAT (15 separating axes) - - no class III: SAT-lite (6 separating axes) - - 4 Toggle leaf nodes - - discarded: use N-1 nodes only for a complete tree - - kept: standard complete tree with 2*N-1 nodes - - 5 Toggle compression - - enabled: use quantized trees - - disabled: use normal trees - - 6 Toggle temporal coherence (only for first contact mode) - - enabled: test the previous pair of colliding triangles - before everything else. - - disabled: well, do not.... - - ----- - - NB: in order to switch from one feature to another quickly, I create - 4 trees for each mesh: normal, no-leaf, quantized, quantized no-leaf. - - i.e. 4 OPCODE models + 1 RAPID model / mesh, which explains why the - building phase is not very fast... Especially in the last scene, it - takes a while - please wait! - - ----- - - Generic keys to play with: - - F1 Texture control - F2 Camera control - F3 Mesh control - F4 Material control - F5 Scene control - F6 Light control - F7 Helper control - - To move the camera or a mesh, use the mouse. Should be intuitive. - In camera mode, press +/- to jump from one camera to another. - Actually +/- jump to "next current" or "previous current", where - "current" is a mesh, camera, texture, etc - depends on selected - control mode. - - To test collision detection, useful keys are: - - S to spin a model automatically (on/off) - - P to pause any animation - - O (in pause mode) to play one frame only - - Other keys shouldn't be useful there but anyway: - - F displays the framerate on/off (BTW, I do 2 collision queries/frame - and displays a lot of slow text, so don't pay too much attention to - the overall framerate) - - T toggles texturing - - G toggles gouraud - - W toggles wireframe - - R toggles the profiling - - I toggles general information - - B toggles bounding boxes - - Special keys - - Y should subdivide a mesh with the Butterfly algorithm. Since it - implies rebuilding all collision trees, it may be quite slow. - - L should smooth a mesh (same remark) - - M should make a mesh manifold, in case ICE complains.... - - U should unfold a mesh, so beware. - - Otherwise, play with the menu *at your own risk*. - - - ----- - - In situations where RAPID is really faster (for example when a mesh - is surrounded by another one) try re-enabling leaf nodes.... - - ----- - - Pierre Terdiman - May 03, 2001 - - p.terdiman@wanadoo.fr - p.terdiman@codercorner.com - - www.codercorner.com - - \ No newline at end of file -- cgit v1.1