• Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By Ricardo3Ddev
      Hi guys!
      This is a independent game being produced by me and my brother. We’ve been working on it for about 6 months and we’ve already done a good part of the game. We hope to finalize and make it available on Steam by the end of this year.
      We are using Blender 3D and Gimp software for production.
       
      About the Game: Dongo Adventure will be a 3D platform style game, where the main character (Dongo) is a mouse that ventures through various scenarios (sewers, culverts, streets, electric grid, etc.) and faces several enemies along the way (cockroaches, mosquitoes, spiders, toxic gases, electrical wires, etc.). He carries a basket / backpack with cheeses that he uses to throw and defend himself from enemies, as well as being able to push objects that helps him to overcome obstacles. The ultimate goal will be a surprise!
       
      Now we are developing new scenarios and enemies. We hope to publish news soon...
      Game page on Steam: http://store.steampowered.com/app/811450/Dongo_Adventure/ - (Teaser UPDATED)
      Dongo Adventure - Indie Game Project (First Teaser) https://www.youtube.com/watch?v=X2nmxtkE0xk
       
      Thanks for following the project!

    • By Epicghost 505
      Hello,
      We are looking for people to be apart of a team, to help create a horror game we are looking for 3d modelers, coders, artist, animators, fx artist, level designers, and audio design, there will be a payment plan once release of game                                                                                                                                                                                                                                                                                              if your interested come join our discord                                                                                                                                                                                                                                                                         We hope to see you there
      https://discord.gg/6rcc6xr
      -Epicghost505
    • By lxjk
      Hi guys,
      There are many ways to do light culling in tile-based shading. I've been playing with this idea for a while, and just want to throw it out there.
      Because tile frustums are general small compared to light radius, I tried using cone test to reduce false positives introduced by commonly used sphere-frustum test.
      On top of that, I use distance to camera rather than depth for near/far test (aka. sliced by spheres).
      This method can be naturally extended to clustered light culling as well.
      The following image shows the general ideas

       
      Performance-wise I get around 15% improvement over sphere-frustum test. You can also see how a single light performs as the following: from left to right (1) standard rendering of a point light; then tiles passed the test of (2) sphere-frustum test; (3) cone test; (4) spherical-sliced cone test
       

       
      I put the details in my blog post (https://lxjk.github.io/2018/03/25/Improve-Tile-based-Light-Culling-with-Spherical-sliced-Cone.html), GLSL source code included!
       
      Eric
    • By Octane_Test
      I am developing a mini golf game in Scenekit. I have applied dynamic physics body to the ball and static physics body to the grass surface and the brick walls show in this image.
      Issue:
      When I apply the force to the ball, the ball’s linear and angular speeds change as shown in the graphs.  The ball’s speeds don’t reduce to zero (so that the ball can stop) but remains constant after certain value.
      Ball linear speed graph
      Ball angular speed graph
      Analysis Tests:
      When I increase the values to both the rolling friction and the friction, the ball speed is reduced quickly but remains constant after certain value (similar to the above graphs). When I increase the values of the linear damping and the angular damping, the ball speed behavior is same as the point #1. When I set the gravity value to -9.8 m/s2, the ball’s linear speed remains constant after 0.1 m/s. If I reduce the gravity value to -5 m/s2, the ball’s linear speed remains constant after 0.05 m/s. The friction, linear friction, linear damping and angular damping are same throughout the motion of the ball.
      There is 1 millimeter overlapping between the ball and the surface of the golf course.
      Questions:
      From the analysis test #3, I think the gravity is causing the constant ball speed issue. Is my assumption correct? If yes, how can I fix the issue? I can’t remove the gravity field as without the gravity field the ball will not roll along the grass and it will slide. Why the friction and the damping properties are not affecting the ball speed after certain value?
      Are there any other physics properties can cause such issue?
      From the analysis test #5, are there any chances that the ball is receiving upward push to correct the position of the ball?
      Solutions:
      If I increase the physics timestep from 60 FPS to 200 FPS, the issue is resolved. I am not able to understand how this change can fix this issue? After reducing the gravity value to -1 m/s2 and physics simulation speed to 4 (4 times fast physics simulation), the issue is fixed. Again, I am not able to understand how this change fix the issue? I would appreciate any suggestions and thoughts on this topic. Thank you.
    • By Sandman Academy
      Downloadable at:
      https://virva.itch.io/sandman-academy
      https://gamejolt.com/games/sandmanacademy/329088
      https://www.indiexpo.net/en/games/sandman-academy
      https://www.gamefront.com/@sandmanacademy
      http://www.indiedb.com/games/sandman-academy
  • Advertisement
  • Advertisement

3D Dynamic Dismemberment and slicing through limbs

Recommended Posts

TL;DR Mesh slicing... Anyone try to venture that way?

So I'm aware of this thread: 

 

 

But since it's from 2004, I wanted to ask.. are there any games since (or ever) that actually have real dynamic mesh slicing?

The only one that I know of that kind of does this is Metal Gear Rising Revenge..?

Anyone know / can guess, how they did this? Is this mesh slicing in real time? It doesn't seem precomputed at least..

I tried myself at programming a mesh slicing algorithm, the other day, but for my routine, at about 200 Vertices it gets too slow for real time.

Using this paper here:

http://www.dainf.ct.utfpr.edu.br/~murilo/public/CAD-slicing.pdf

(Obviously some bugs, face orientation messes up, and I have to say it was completely on the CPU, and didn't spend much effort optimizing anything)

slicing-01.gif

Edited by teutoburger
missing info

Share this post


Link to post
Share on other sites
Advertisement

Look at this: 

 

really a good game as well.

Slicing definitively realtime, remember software rendered games which did this for every polygon intersecting a frustum plane.

Maybe look for polygon clipping.

Here is a routine that i use in a preprocessing tool, but you need to build and triangulate the large poly where the volume intersects the plane alongside:

Edit: Thinking of it, you should use only convex polyhedra, so slicing always results in only convex polygons.

Complex shapes can be made by multiple convex shapes (like we do for physics collision detection).

And if you have poly adjacency information at edges, you can slice in order so the volume poly emits in correct order as well and no searching is necessary to connect unordered split edges. This way you also quickly reject polys that do not intersect the splitting plane.

 

 

	inline int32_t ClipTexmapPolygon (const TexmapPolygon *pin, const vec &plane, TexmapPolygon *pout, const int32_t space)
	{
		if (pout->numAvailableVertices < pin->numVertices + 1)
			pout->Resize (pin->numVertices + 1);

		int32_t i, curin, nextin;
		float curdot, nextdot, scale;
		TexmapPolygon::Vertex *pinvert, *poutvert, *nextvert;

		pinvert = pin->vertices;
		poutvert = pout->vertices;
		curdot = pinvert->puv[space].Dot (plane);
		curin = (curdot >= plane[3]);
	
		int32_t ret = -1; // assume inside

		for (i=0; i<pin->numVertices; i++)
		{
			nextvert = &pin->vertices[(i+1) % pin->numVertices];
			// keep if inside	
			if (curin) 
			{
				*poutvert++ = *pinvert;
			}
		
			nextdot = nextvert->puv[space].Dot (plane);
			nextin = (nextdot >= plane[3]);
			
			if (curin!=nextin) // add clipped vertex if plane splits edge
			{
				assert (fabs(nextdot - curdot) > FP_EPSILON);
				ret = 1; // clipped or outside
				scale = (plane[3] - curdot) / (nextdot - curdot);

				for (int32_t c=0; c<3; c++)
					poutvert->puv[c] = pinvert->puv[c] + (nextvert->puv[c] - pinvert->puv[c]) * scale; // position and 2 uc channels

				poutvert++;
			}

			curdot = nextdot;
			curin = nextin;
			pinvert++;
		}

		pout->numVertices = int32_t(poutvert - pout->vertices);
		if (pout->numVertices < 3) return 0; // outside
	
		return ret;
	}

 

Edited by JoeJ

Share this post


Link to post
Share on other sites
12 hours ago, JoeJ said:

And if you have poly adjacency information at edges

something like a winged edge structure, right?

 

12 hours ago, JoeJ said:

This way you also quickly reject polys that do not intersect the splitting plane.

I think I get the idea of how the triangle adjacency information allows you to disregard the majority of triangles. Correct me if I'm wrong.. 

(1)Make an empty Set L of triangles (edges) T that intersect the plane.

(2) Pick any triangle (or edge) T that intersects the plane. (I have questions about this step actually*..)

(3) Add T to L. 

(4) Regard each adjacent triangle (edge) of T and check if it is intersecting the plane. If it isn't, you can disregard all its adjacent triangles (edges) (herein lies the major part of the optimisation for this algorithm). If one of them does intersect the plane, you take it as your current T and repeat the step.

 

*How do you find the very first T, that intersects, without looking up every triangle in the mesh until you hit one that intersects the plane? So the worst case is you check them all, the average case is somewhere around 1/2'N checks? Or is there a much better way that I'm missing here?

 

 

Edited by teutoburger

Share this post


Link to post
Share on other sites

Regarding 

ClipTexmapPolygon (const TexmapPolygon *pin, const vec &plane, TexmapPolygon *pout, const int32_t space)

This routine constructs the intersection polygon of mesh and plane, right? Its a 2d polygon.

Viewing the parameter list, why is one vec enough to define the plane? Shouldn't there be a distance and a normal? Or a Point-on-plane and a normal?

Share this post


Link to post
Share on other sites
59 minutes ago, teutoburger said:

something like a winged edge structure, right?

Not sure what that is, but i mean for each edge have indices to left / right triangle. Further The whole mesh needs consistent winding order (each triangle has clockwise vertices. The mesh needs to be closed... the typical requirements).

59 minutes ago, teutoburger said:

I think I get the idea of how the triangle adjacency information allows you to disregard the majority of triangles. Correct me if I'm wrong.. 

Find a edge that intersects the plane, split it and go to the left trianlge, find the other edge of that triangle that intersects the plane and continue with the other triangle from that edge until you get back to the starting edge. During that add each split point to the volume / plane intersection polygon. 

No Set required. Processing any edge just once. Works only for convex meshes (otherwise need to find all starting edges, not just any single one).

It's like cutting a mesh made of paper with a scissor, so just in order vs. poking individual cuts into random triangles like traditional frustum clipping would do. 

(I've just implemented tracing a crossfield on mesh surface, which is pretty similar and i used this simple algorithm without issues.)

 

59 minutes ago, teutoburger said:

*How do you find the very first T, that intersects, without looking up every triangle in the mesh until you hit one that intersects the plane? So the worst case is you check them all, the average case is somewhere around 1/2'N checks? Or is there a much better way that I'm missing here?

Yeah you are right - the need to find a single intersecting edge kinda destroys the advantage we do not walk to triangles not touching the plane while cutting.

But you could speed this up when everything else works as well: 

Pick a random vertex and select the edge closest to the plane, continue until you find an intersecting edge.

Again this works only for the convex case (and you may need more adjacency information like vertex knowing all its edges - pretty annoying to maintain ;)

Edited by JoeJ

Share this post


Link to post
Share on other sites
22 minutes ago, teutoburger said:

This routine constructs the intersection polygon of mesh and plane, right? Its a 2d polygon.

Viewing the parameter list, why is one vec enough to define the plane? Shouldn't there be a distance and a normal? Or a Point-on-plane and a normal?

All 3D. The routine processes a polygon with an array of 3 3D vectors, 'puv'. (I store 3D position and uv channels there)

My vec has storage for 4 numbers, so in this case i use plane[3] to store the plane distance to the origin. (confusing, but seems i was too lazy to create a plane class.) 

The original code came along Michael Abrashs Graphics Programming Black Book.

 

 

 

Share this post


Link to post
Share on other sites
11 minutes ago, JoeJ said:

Works only for concave meshes

just to remove any ambiguity here, convex(?), you probably meant to say convex here, right? 

 

Share this post


Link to post
Share on other sites
30 minutes ago, JoeJ said:

Works only for concave meshes

wait.... I think it would work for all convex meshes and also for those concave meshes without inner holes.

 

 

Share this post


Link to post
Share on other sites
17 minutes ago, teutoburger said:
30 minutes ago, JoeJ said:

Works only for concave meshes

just to remove any ambiguity here, convex(?), you probably meant to say convex here, right? 

Ooops, i did it again. Convex is right, yes - fixed.

Share this post


Link to post
Share on other sites
Just now, teutoburger said:

wait.... I think it would work for all convex meshes and also for those concave meshes without inner holes.

Yes, but you need to find multiple starting edges.

But the mentioned optimization to find a start edge would fail: I could get stuck in a sink. (I'm not sure at what complexity this optimization would be a win anyways, due to the need to maintain more adjacency).

 

There is however a algorithm to calculate a cut graph for a mesh that cuts it to a topological disc. (Using spanning tree and it's dual, i'd need to look it up...) Eventually you could precompute that cut graph, and then only check those edges to find intersecting edges. But i need to think about this for some time - not sure if it works yet... (Also unsure if you'd need to recalculate this graph for sliced pieces so you can slice tham again - that would be much worse than just checking all edges.)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now


  • Advertisement