# pinknation

Member

34

126 Neutral

• Rank
Member
1. ## Triangulation of Sliced Triangle Hull, and some good algorithms.

So, I have a picture here that will help a lot with my question: excuse the poor drawing if possible, anyways, the point here is that if I have a convex hull such as in Diagram 1, the teapot, and I slice on on that red line, from the top-down view, the slice points(otherwise the inverse of the plane) will look like that in 2D. is there any good triangulation algorithms which can a) support holes, and b) support edges/points seperated from each other creating sub polygons, but all within the same triangulation sweep; this is important, and any information would be great, I am capable of learning, but looking for something more open-source that i can try and understand better then a PDF, but anything will do
2. ## [Theory] Unraveling the Unlimited Detail plausibility

To my above post which I cannot edit, I ment to say convert the 2D layers to radial, oh geeze I've been confusing those two a lot lately;
3. ## [Theory] Unraveling the Unlimited Detail plausibility

try thinking more outside the box guys, unlimited detail isn't something that Bruce Dell found in some PDF file on rendering unlimited detail. He invented it, basically going against all other current techniques for rendering point data; My gist of all this, is that the entire world(not just individual models and objects in the world), are sliced into 2D layers, and converged into cartesian coordinates; these coordinates are then during run-time almost magically reverse transformed to their proper screen-space coordinates after already being sorted through some unknown function; Don't like that approach? We'll octree's have not been able to yeild those results in real-time either; So, lets try and take down the number of cycles, and complicated maths and leave it more simple, that's the only way he could process that much information in such a small amount of time. Accept it and move towards that; Computational Theory; I'd also say that ray-tracing is really not the answer here as he states Thinking outside the box might be an example of this based on the cartesian idea, that is the screen-space may not be nothing more then some normals right, and just like when righting a script to do reflection, and refraction, you're no more moving a few pixels in the direction of that normal. So lets transform our cartesian coordinates with some dot product to our screen-space normal; what might happen then? Magical reverse transformation of the exact "atom" we need for that point on the screen. Without a lot of cycles; Or math. This guy's been developing this thing for a long time, and deserves more respect for not having stuck to standards, and simply accepting the PDF's or Tutorials they find on GameDev as their ultimatum. He went around and beyond, I say you stop fighting it, and embrace it; Just because he hasn't decided to populate it yet, does not mean that it isn't there. Give him time to perfect it, and make some affiliations with physics companies, who can then compute on the GPU while all graphics processing is being done on the CPU. This type of co-proccessing is what is going to make next-gen games next-gen; Be patient;

5. ## GLSL Problems...

Vertex Shader: // wave functions /////////////////////// struct Wave { float freq; // 2*PI / wavelength float amp; // amplitude float phase; // speed * 2*PI / wavelength vec2 dir; }; #define NWAVES 2 Wave wave[NWAVES] = { { 1.0, 1.0, 0.5, vec2(-1, 0) }, { 2.0, 0.5, 1.3, vec2(-0.7, 0.7) } }; float evaluateWave(Wave w, vec2 pos, float t) { return w.amp * sin( dot(w.dir, pos)*w.freq + t*w.phase); } // derivative of wave function float evaluateWaveDeriv(Wave w, vec2 pos, float t) { return w.freq*w.amp * cos( dot(w.dir, pos)*w.freq + t*w.phase); } // sharp wave functions float evaluateWaveSharp(Wave w, vec2 pos, float t, float k) { return w.amp * pow(sin( dot(w.dir, pos)*w.freq + t*w.phase)* 0.5 + 0.5 , k); } float evaluateWaveDerivSharp(Wave w, vec2 pos, float t, float k) { return k*w.freq*w.amp * pow(sin( dot(w.dir, pos)*w.freq + t*w.phase)* 0.5 + 0.5 , k - 1) * cos( dot(w.dir, pos)*w.freq + t*w.phase); } uniform float time = .0; uniform float waveAmp = .15; uniform float waveFreq = .5; void main() { wave[0].freq = waveFreq; wave[0].amp = waveAmp; wave[1].freq = waveFreq*2.0; wave[1].amp = waveAmp*0.5; vec4 P = vec4(gl_Vertex); P.y = 0.0; float ddx = 0.0, ddy = 0.0; for(int i=0; i<NWAVES; i++) { P.y += evaluateWave(wave, P.xz, time); float deriv = evaluateWaveDeriv(wave, P.xz, time); ddx += deriv * wave.dir.x; ddy += deriv * wave.dir.y; } vec3 B = vec3(1, ddx, 0); vec3 T = vec3(0, ddy, 1); vec3 N = vec3(-ddx, 1, -ddy); gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0; gl_TexCoord[1] = gl_TextureMatrix[0] * gl_MultiTexCoord0; gl_Position = gl_ModelViewProjectionMatrix * P; } Fragment Shader: sampler2D TextureUnit0; sampler2D TextureUnit1; float scale = 5.0; void main() { vec4 c1 = tex2D(TextureUnit0, gl_TexCoord[0].st * scale); gl_FragColor = c1; } If i was to change "gl_FragColor = c1;" in my fragment shader to "gl_FragColor = vec4(1, 0, 1, 1);" the waters' surface, as this shader simulates, will become animated, however, without changing that line to some hard-coded color(not obtaining the color from texture2D), it becomes frozen, and doesn't move. [Edited by - pinknation on January 27, 2010 1:00:59 PM]
6. ## NN-Search Problems for Fluid Dynamics / Collision

Hi there, I've been writing a "Particle Based Hydrodynamics" engine, in C++ using SSE for optimization.. SSE increased the speed a lot, but in the end things began to slow down do to O(N^N-1) collision detection, so I've decided to implement the kd-tree, so far I've been un-able to properly write the Nearest Neighbor search, and am beginning to have issues w/ kd-tree all together, because the wikipedia doesn't describe the proper way to 'balance' the tree(because none of my tree leafs should remain static, the tree should be re-balanced every frame, for optimization); I could do this the 'brute' way which starts from the root, and balances the tree.. just like I did to build it(using axis based median sorting); though that seemed like it maybe slow?? (of course it should still be faster then re-building the entire tree.. which im currently just doing every-frame LOL) I'm wondering if anyone knows of a better solution than kd-tree, and otherwise, if someone could help explain nearest neighbor search.. my current NN-search is like this: void find_neighbors(SSEBoundingSpheres &spheres, kdnode* node, kdnode *cnode, std::vector<int> &neighbors, float r, float min_dist = FLT_MAX) { if( node == 0 || cnode == 0 ) return; if(cnode->id != node->id) { float dir; if(node->axis == 0) dir = (spheres.position_x[node->id].m[0] - spheres.position_x[cnode->id].m[0]); else if(node->axis == 1) dir = (spheres.position_y[node->id].m[0] - spheres.position_y[cnode->id].m[0]); else if(node->axis == 2) dir = (spheres.position_z[node->id].m[0] - spheres.position_z[cnode->id].m[0]); if(dir < 0.0) { find_neighbors(spheres, node, cnode->left, neighbors, r); if(dir*dir<r) { neighbors.push_back(cnode->id); find_neighbors(spheres, node, cnode->right, neighbors, r); } } else { find_neighbors(spheres, node, cnode->right, neighbors, r); if(dir*dir<r) { neighbors.push_back(cnode->id); find_neighbors(spheres, node, cnode->left, neighbors, r); } } } } which is a recursive function, and doesn't appear to properly find all contacts.. actually the radius is greater than all the particles, so during the initial NN-Search I should see all of the particles as neighbors, but I don't.. ;_; thanks to anyone who can help resolve this. =]
7. ## Optimized Collision Detection & Physics

thanks again Flounder. <3 not 100% sure why I did that.. think I'm done w/ help for now, unless anyone can explain how to solve the collision issue..
8. ## Optimized Collision Detection & Physics

It's all good, thanks.. I'm just having issues now with particles colliding with one another, after the collision tests have completed. :[ I've been reading up on more collision detection & response, though I'm not understanding how to resolve this problem in an non-costly manner, like all that keeps coming to mind is 'BRUTE-FORCE BRUTE-FORCE BRUTE-FORCE'. ^_^
9. ## Optimized Collision Detection & Physics

yeah, understandable, I went ahead and listened to you guys: void BroadPhaseCollision() { grid->Refresh(particles, particles_length); for(int i = 0; i < grid->Width * grid->Height; ++i) { for(unsigned int j = 0; j < grid->m_grid.size(); ++j) { Particle p1 = particles[grid->m_grid[j]]; for(unsigned int k = j + 1; k < grid->m_grid.size(); ++k) { Particle p2 = particles[grid->m_grid[k]]; if(p1.id == p2.id) continue; float d_x = p2.p_x - p1.p_x; float d_y = p2.p_y - p1.p_y; float R = p1.radius + p2.radius; if(R * R > d_x * d_x + d_y * d_y) NarrowPhaseCollision(particles[grid->m_grid[j]], particles[grid->m_grid[k]]); } } } } its actually faster(at least its not as slow as it was before with 400 particles), though the collision itself is still acting funny.. I'll continue to try and figure that out :[ The problem is, that after the collisions are dealt with, more collisions are created, though its finished checking for collision, and continues to update the particles, resulting in a rather buggy Simulation.
10. ## Optimized Collision Detection & Physics

it shouldn't matter if I swept through cells, or particles.. because either way I'd loop through each particle, adding the cell loop, would simply add an extra loop. Edit: Would AABB method of collision detection be better? Currently I am using a Spatial Index Grid.. which I've seen used in SPH systems.

12. ## Optimized Collision Detection & Physics

@Flounder, thanks! I've resolved that, actually a noticeable speed-boost! Thanks, much! @Felix, you're right... that is exactly why! That's why I've included the collision detection, to avoid them becoming super close, however, during the Collision Detection Sweep, it pushes two colliding particles away from each other, and sometimes even pushes one of them, directly into another, causing it to 'shoot off'. That's what I was trying to explain in my original post, that I need a better method of Collision Detection, because my current solution doesn't solve each collision, before updating the physics.
13. ## Optimized Collision Detection & Physics

uhm, Felix, your optimizations only made things buggy.. >.> @flounder: thanks, uhm, about the multiplying by .5f, that was just a quick way for me to add friction, so nevermind that :P; as for what you said about the sqrt thing.. that only made it buggy.. :S the 'buggy' that I refered to for both of you, was the particles began to vibrate, and/or not move