Jump to content
  • Advertisement
Sign in to follow this  
G-Man9566

Grid creation

This topic is 3960 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I want to create a grid for a 3D editing program, in 3 ortho and 1 perspective view. I was wondering if anyone would have an idea what would be the most efficient way of doing this. I was thinking of using D3DXLine or maybe creating it with DrawPrimitive, but it seems to me that these 2 methods might hamper the frame rate. I suppose that a textured quad could work for the perspective though? Giving the parts with no lines a transparency. But I'am not sure that that would work for the ortho views. What do you think? PS: I'm using D3D9

Share this post


Link to post
Share on other sites
Advertisement
I know there was some reason why I did not use D3DXLine but I cannot recall why. I used DrawPrimitive to draw the buffer: The buffer of lines that make up the grid behaves similar to typical 3D editing IDEs (e.g. 3dsMax). I have 10 x 10 major grid lines initially 10 units apart and another 10 X 10 grid lines intially 1 unit apart within each major (10X10 units) grid. It also scales on zooming. And any hampering of frame rate due to rendering the grid is not detectable. i.e. whether I draw the grid or not the frame rate does not change. So you could try DrawPrimitive ( and render what, a measley max 200 lines all up?)

Then again you try something else that might end up being better/having it's advantages in certain situations, and then you can tell us about it. :)

Share this post


Link to post
Share on other sites
Hey thanks. I was also voting for the DrawPrimitive method. Was just wondering what you all think.

I am going to try the DrawPrimitive method first and will let you know how it went.

Share this post


Link to post
Share on other sites
Hi. How do we do it using openGL. As like in 3ds max, in any 2d view port, the grid never ends no matter how much you zoom in.
How can we do this.

Share this post


Link to post
Share on other sites
That is a very good question? I also don't know yet, but I intend to find out. I would like to do it in D3D9 though :)

Does someone have an idea where to start?

Share this post


Link to post
Share on other sites
Just my humble opinion on how I would try and solve it:
You may use a scale matrix to adjust your lines as you zoom in and out?

e.g Horizonal lines scales in x-direction etc.


float ZoomAmt = GetZoomAmount();

D3DXMATRIX HorizontalZoom;
D3DXMatrixScaling(&HorizontalZoom, ZoomAmt, 1.0f, 1.0f);

pDevice->Transform(D3DTS_WORLD, HorizontalZoom);
pDevice->DrawPrimitive(D3DPT_LINELIST, 0, NumLines);


ZoomAmt will range from (0, any amount], as having it as 0.0f will make the scale wrong.

I am sure there are many other methods to do it too.

Share this post


Link to post
Share on other sites
hi guys,
Quote:

Does someone have an idea where to start?


Finding a starting point for this is probably one of the hardest parts of the problem (i.e. you could end up spending more time figuring out how to do it, and relatively very little time actually implementing it). Plus, it is probably one of the less interesting/less important features in an editing/viewing program (i.e. its trivial/ illiciting little if any kudos). So, in a way, it makes for an interesting little feature to add a little extra polish to you app (Attention to the small details such as this enhances the prestige (and price) attached to professional software of choice). The tessellation state of the grid is really another little tool, that helps inhibit disorientation of the user while viewing (among other things) a 3D space. So for this to work well we would really like to tessellate and un-tessellate the grid consistently at all zoom distances.

Just to clarify: you are talking about the granularity of the grid changing as the zoom distance of the 'camera/zoom lens' changes. For example: you may start out with the sample grid I gave above where the distance between minor lines is one unit, and distance between major lines(slightly darker lines) is 10 units. Then while you zoom in, at some point you notice the the 1 unit grid lines 'tessellate' into ten more grid lines (say 0.1 units apart) and the 1 unit grid lines change to major grid lines(i.e. they turn to the darker major grid line color) ...and so on.

littlekid has the right idea (i.e. we know we need to do some sort of scaling), even if the idea is a little incomplete (i.e. We also need to, contrive a way, of knowing when to re-scale the grid consistently.)

Here are some more ideas to help:

Choose a metaphor to describe a problem. I see 2 likely candidates:
(1) Camera with zoom lens.
Rely on the focal length of a zoom lens as the variable critical to solving the problem i.e. to derive the scaling info.
For example, could go as far as having a camera with a 35 - 105mm zoom lens attached. You could even have a camera with a zoom lens that has an initial focal length that is arbitrarily defined by you and derive the scaling (i.e. the changes in focal length when zooming). The idea here is that the changes in focal length are more important than the initial arbitrary focal length(scale value). Then when it comes time to process the grid, the focal length 'becomes' just a scalingFactor applied to the grid (yeah, from the grid's point of view, if it has one?) in order to tessellate/untessellate the grid.

(2)Grid.
This is a more direct approach minimising the use of abstractions/metaphors/code, by concentrating only on the state of the grid and its direct relationship to its viewport. This is the approach we took: it looked like less work at the time, and we basically saw no need for a "camera with a zoom lens" concept just to tessellate/untessellate a grid. However you may see more benefits in using the camera metaphor. In fact, I wouldn't mind seeing someone's example that uses the camera or some other metaphor for comparisons (since, I ain't gonna make another implementation myself).

Grid Zooming to Infinity! Well...not really, but almost ;)

What We Did
The implementation of this feature is as independant, of the graphics API, as possible. That is, whether you use OpenGL or Directx is made as irrelevant at possible (e.g. only relevant in render time code). This is done to take advantage of all those good things about OO we like so much (hopefully you know what they are?).

What We Used
Basically 3 main variables (there are a few others) and a constant number of grids that get tesslated/untessellated by changing the distance between gridlines. The constant number of grids helps provide an initial 'known' efficient rendering performance (i.e. we always know how many lines will be drawn). However, you may also want to vary this later, but we initially maintain it as an invariant to concentrate of the 'basic 3 vars', provided below.

Variables/ Variants
gridScaleFactor: the ratio of 3D world units to pixels on the grid plane. Other ways of looking at this is as "The number of world units between pixels" or "The number of pixels per world unit", all of which amount to different derivations of the same thing. The one to use is "The number of world units between pixels". This seems a bit over the top, even to me. But what it will do is allow us to always derive a true indication of how many grid lines are currently visible in the viewport. Why would we want that? We can use the number of gridlines currently visible in the viewport as the thresholds used to consistently (I repeat, consistently) tessellate/untessellate the grid during zooming. (RE: How we get "the number of world units between pixels" is another story.)

Tessellation/simplification thresholds.
we can tessellate/untessellate the grid consistently (based on the number of grid lines currently in the viewport[or a percentage thereof]). For example, let's say initially each grid we see is 1X1 world units(wu) square and there are 6 grids displayed across the x axis of the 2D viewport. Lets say we start zooming out. At some point we want the grid to untessellate so that we end up with only six grids across the x axis of the viewport again, but this time each grid will represent a square 10X10 world units. If we continue zooming out, at the next simplification (untessellation) we will have again have 6 grids displayed across the x axis of the viewport. This time each grid will represent a square 100X100 world units..and so on.
To make this happen we can untessellate the grid every time the threshold of 60 gridlines across the x axis of the 2d viewport is exceeded.

To make tessellation happen while we zoom in: every time there is less than 6 grids displayed across the x axis of the 2d viewport we tessellate.
For example, let's say initially each grid we see is 1X1 world units(wu) square and there are 6 grids displayed across the x axis of the 2D viewport. Lets say we start zooming in. As soon as there is less than 6 grids across the x axis of the viewport tessellate, so that we have sixty grids (0.1X0.1 wu square) across the x axis of the 2d viewport. If we continue zooming in, the next tessellation will occur the next time there is less than 6 grids displayed across the x axis of the 2D viewport. After tessellation we again have 60 grids across the x axis of the 2d viewport (this time each grid will be 0.01X0.01 wu square) ...and so on.

So we can use 2 thresholds: a maximum of 60 gridlines, and a minimum of 6 gridlines.
Whenever more than 60 grids are visible (across x axis of the 2D viewport) the grid is simplified to 6 grids.
Whenever less than 6 grids are visible (across x axis of the 2D viewport) the grid is tessellated to 60 grids.
The function that does this tessellating/untessellating doesn't even need to know if the user is zooming in or out.

Note: We don't actually use Thresholds of 60 and 6 they are just an examples.

Well, this all seems like a lot of work to me for a minor feature, especially after trying to explain it ( I must be feeling in a verbose mood; I usually don't bother trying to explain myself, but usually provide references instead. I just haven't found any for this...yet?). Ultimately, there is not much code involved, and it is efficient (i.e. as mentioned in my earlier post 'any hampering of frame rate due to rendering the grid is not detectable' whether zooming or not).

I hope this helps. There are some more complex details I left out, so if you need further explanations...just ask.. hopefully my verbose mood may last long enough to help. :)

Is it worth it?
(I keep on saying to myself: there has got to be a simpler way; but I haven't seen one yet... then again... I say that about alot of things, rightly or wrongly).
So, as usual, it would be good to hear from someone else who has actually implemented this feature successfully, but differently, as in using the camera metaphor/or used a simpler method.

PS. One other thing, you will eventually need to consider adjusting the near and far clipping planes of the viewing volume while zooming, for the grid and 'things' in you scene to remain visible in the viewport.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!