Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 07:58:01 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)The grumpy old programmer room
Pages: 1 ... 201 202 [203] 204 205 ... 295
Print
Author Topic: The grumpy old programmer room  (Read 733470 times)
insyzygy
Level 0
**


View Profile
« Reply #4040 on: April 10, 2013, 05:19:46 PM »

Marching cubes is a bitch. Accounting for 256 possible cases plus normals data is not a small task. The tenons in my right wrist are soar from typing array entries.
Write code to generate the table / use an existing lookup table.

For the general algorithm I did use pre-existing tables, however to actually draw the triangles in the engine I'm using I have to supply the index data for each case.
Logged
Crimsontide
Level 5
*****


View Profile
« Reply #4041 on: April 10, 2013, 09:13:17 PM »

Marching cubes is a bitch. Accounting for 256 possible cases plus normals data is not a small task. The tenons in my right wrist are soar from typing array entries.
Write code to generate the table / use an existing lookup table.

For the general algorithm I did use pre-existing tables, however to actually draw the triangles in the engine I'm using I have to supply the index data for each case.

But in marching cubes the tables are the index data.
Logged
Geti
Level 10
*****



View Profile WWW
« Reply #4042 on: April 10, 2013, 10:02:09 PM »

What crimsontide said. The only thing you need to do a lookup for in marching cubes is getting the surface representation from the per-voxel generated bitfield.
You can generate that table from the (15?) base configurations by transforming them (and their associated normals, you can keep the vertex indices because you're not changing the order). A handwritten table is a waste of time.
Logged

Crimsontide
Level 5
*****


View Profile
« Reply #4043 on: April 10, 2013, 11:09:47 PM »

What crimsontide said. The only thing you need to do a lookup for in marching cubes is getting the surface representation from the per-voxel generated bitfield.
You can generate that table from the (15?) base configurations by transforming them (and their associated normals, you can keep the vertex indices because you're not changing the order). A handwritten table is a waste of time.

I just copy/pasted mine from a website.  I can paste the table in here if you so desire.
Logged
insyzygy
Level 0
**


View Profile
« Reply #4044 on: April 11, 2013, 03:12:31 AM »

I see the wisdom of your words, but I think it's more complicated than just generalizing from the 15 cases. The way I'm doing it, the vertices get computed in a specific order for each cell in such a way that the vertices aren't always ordered the same relative to each other across instances of the same case. So if I just define 1 set if indices for each case, some triangles are going to get flipped. The obvious solution is to get rid of backface culling, but I only want to do that if forced to.

The table used for actually computing the vertices was not hand-written, I got it from a website (probably the same one crimsontide found).
Logged
Crimsontide
Level 5
*****


View Profile
« Reply #4045 on: April 11, 2013, 09:07:50 AM »

I see the wisdom of your words, but I think it's more complicated than just generalizing from the 15 cases. The way I'm doing it, the vertices get computed in a specific order for each cell in such a way that the vertices aren't always ordered the same relative to each other across instances of the same case. So if I just define 1 set if indices for each case, some triangles are going to get flipped. The obvious solution is to get rid of backface culling, but I only want to do that if forced to.

The table used for actually computing the vertices was not hand-written, I got it from a website (probably the same one crimsontide found).

Ensuring the winding order of triangles is valid is trivial, hence no need to remove backface culling.  But that's not the issue here.

The vertices are created along the cube's edges, 12 to be exact.  The order/positioning of the edges is ordered and does not change.  Geti is correct, in the original marching cubes paper the 256 cases are actually derived from 15 unique cases which are just rotated/mirrored a half dozen times.  So whether you have a large table that handles all possible 256 cases, or generate one from the original 15, it's pretty much the same thing.

You mentioned having problems with normals and stuff about handwritten tables which has me kinda confused.  The normals are generated in the same way as vertex positions, and any other vertex-specific data (texture coords, colors, blending coefficients, ect...).  The vertices of the cube are not vertices in the final output, think of them like control points.  You generate the 8 control points (perhaps from voxel data, perhaps dynamically, its all the same) and the control points can have more than just position data, they can have texture mapping coords, normals, colors, anything really with them.  Now you create your 12 edge vertices by linearly interpolating the adjacent control points along each edge.  Your interpolation 'amount' is determined by the iso-surface values at each of the 2 control points you're interpolating across, and the iso-surface threshold that defines the surface (you're doing that right?).  This will give you up to 12 vertices (in the case where both control points of an edge are on the same side of the iso-surface threshold, you won't get a vertex).  These 12 vertices will have position data, possibly normal data, color data, texture data, and whatever else you want.

Now you need to store these edge vertices in a vector, possibly array, vertex buffer, or whatever.  As you add them (in order) store the current offset of each vertex in a temporary variable.  This is its index.  You can now discard the 12 vertices, all you need is their indices which you have (well mentally discard, you don't need to really discard them as they are probably just a small array of temporary variables defined at the begining of the function).

Now you use the 8 control points to look up the marching cube 'case'.  Each of the 8 control points are either in or out, which is mapped to a 0 or 1 depending on how you generated the table and/or where you pilfered it from (like in my case ; ).  Or'd together the 8 'bits' now give you the marching cube 'case'.  This will be a list of indices into the 12 edge vertices.  Now you start adding indices to your index vector/array/buffer/whatever.  For example if the list says '0, 8, 3' then you push to the index vector/array/buffer/whatever the index you previously stored for edge vertex 0, then the index for edge vertex 8, then the index for edge vertex 3.

The triangles generated will always be in the winding order that the table specifies, so backface culling will work.  The actual vertex data can store anything that can be linearly interpolated; normals, colors, texture coords all work fine.  Does that make sense?
Logged
insyzygy
Level 0
**


View Profile
« Reply #4046 on: April 11, 2013, 10:50:44 AM »

It's strange, my implementation is almost exactly like what you just described, but for some reason I had it in my head that I had to write out the indices by hand. Something about the way you just said that made it click for me. I am significantly less grumpy now.
Logged
Crimsontide
Level 5
*****


View Profile
« Reply #4047 on: April 11, 2013, 11:21:11 AM »

12 vertices actually means a lookup table of size 4048. Still pretty tedious to fill by hand.

No the look-up table is 256 entries.  Each corner of the cube (aka control point) is compared vs the iso-surface threshold (also called iso-value).  If its less than the iso-value you give the control point a 0, if its larger a 1 (or vice-versa depending on how your tables are set up).  This gives you 8 bits (1 for each corner of the cube).  This in turn gives you your 256 'cases'.  These cases will index the 12 edge vertices, but there are only 256 cases to consider.

Still far more than I'd want to do by hand.  I took the lazy route and copied someone else's ; )
Logged
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #4048 on: April 11, 2013, 11:28:47 AM »

Dammit, I deleted my stupid comment in 5 seconds and still someone quotes it. I guess I cannot count.
Logged
Crimsontide
Level 5
*****


View Profile
« Reply #4049 on: April 11, 2013, 11:32:44 AM »

Dammit, I deleted my stupid comment in 5 seconds and still someone quotes it. I guess I cannot count.

LOL, its ok.  I've done that so many times that I've lost count.

Beer!
Logged
Will Vale
Level 4
****



View Profile WWW
« Reply #4050 on: April 11, 2013, 02:40:09 PM »

No problem, I thought - Mercurial saves reverted files as .orig, except in my case it hadn't.
It turns out this was because TortoiseHG has a little tiny checkbox which turns this feature off - must've accidentally checked it. So it wasn't the UTF-16.

Oh well, at least I now have full text diffs again.
Logged
bateleur
Level 10
*****



View Profile
« Reply #4051 on: April 17, 2013, 01:17:23 PM »

So, I have two Rigidbodies, rb1 and rb2. I need to do a few calculations and obviously mustn't mix the two up.

Today my code would have been on average more often correct if I'd flipped a coin for which one to use each time. Facepalm

Hey, wait a sec... do you think I maybe might get it right more often if I gave them more descriptive names? Roll Eyes
Logged

Will Vale
Level 4
****



View Profile WWW
« Reply #4052 on: April 17, 2013, 01:23:02 PM »

A and B!
Logged
kamac
Level 10
*****


Notoriously edits his posts


View Profile
« Reply #4053 on: April 17, 2013, 01:25:04 PM »

Dammit, I deleted my stupid comment in 5 seconds and still someone quotes it. I guess I cannot count.

You're famous. How does it feel?
Logged

BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #4054 on: April 18, 2013, 01:01:58 PM »

I guess i should make gaffes more often - there's nothing people like more than picking up on them.
Logged
Player 3
Level 10
*****


View Profile
« Reply #4055 on: April 21, 2013, 03:35:56 PM »

I feel like I'm committing some form of cardinal sin by using goto a lot in my C++ II final project.
Logged
Belimoth
Level 10
*****


high-heeled cyberbully


View Profile
« Reply #4056 on: April 21, 2013, 03:37:49 PM »

You are.

Sin boldly.
Logged

mr_gant
Level 0
**


View Profile
« Reply #4057 on: April 21, 2013, 06:26:17 PM »

I can't work out what's causing these weird ghost vertices to appear:


(Link to same view with lines mode)

Drawn in lines mode, it looks fine, if a little choppy.

I can work around it by smoothing my mountains, but that's no fun at all.

Any ideas on how to diagnose this kind of issue?
Logged
Schrompf
Level 9
****

C++ professional, game dev sparetime


View Profile WWW
« Reply #4058 on: April 22, 2013, 02:57:36 AM »

PIX. Or whatever GPU debugger your OS and 3D API offers to you.

I don't know if I actually spotted the real problem, but to me this looks like some triangles are backwards and backface culling shows them from certain angles.
Logged

Snake World, multiplayer worm eats stuff and grows DevLog
ham and brie
Level 3
***



View Profile
« Reply #4059 on: April 22, 2013, 05:52:48 AM »

Or it's not the back faces but that it's overlapping front faces and blending additively?
Logged
Pages: 1 ... 201 202 [203] 204 205 ... 295
Print
Jump to:  

Theme orange-lt created by panic