• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ak09

How can I change [-1,1] range from gluPerspective?

10 posts in this topic

I'm drawing 2D, on different layers, dealing with real coordinates [(0,0), (screenWidth, screenHeight)] instead of the standard [-1,1]. And everything is ok when using gluOrtho2D(0, w, h, 0).

However, I want to be able to render those layers in a 3D space, so the user can merge in the scene. The problem is: with gluPerspective, all my coordinates are changed, and for the reason I'd have to change them all in my code, this is strictly unwanted.

So, is there a (simple) way to solve my thing?
 

0

Share this post


Link to post
Share on other sites

That is the job of the view matrix.

 

A scaling and a translation will make sure that the coordinates in x/y-plane from 0,0 to w,h is mapped to the screen.

0

Share this post


Link to post
Share on other sites

That is the job of the view matrix.

 

A scaling and a translation will make sure that the coordinates in x/y-plane from 0,0 to w,h is mapped to the screen.

Sorry, but this is a little vague to me.
All I'm doing is making a perspective change before every texture draw — since they can have different sizes — with:
 

void setPerspective(int w, int h)
{
    glViewport(0, 0, w, h);
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    gluOrtho2D(0, w, h, 0);
    glMatrixMode(GL_MODELVIEW);
}
 

 

By replacing my gluOrtho2D with gluPerspective, what changes shoud I make and where?

0

Share this post


Link to post
Share on other sites

You need to use different coordinates for your vertices since the coordinate systems are completely different. For a given vertical FOV and aspect ratio, you can calculate the range in X and Y direction at a certain depth Z.

 

yrange = Z*tan(fov/2);
xrange = yrange*aspect;

The range of the coordinate system at depth Z is from -xrange to xrange in the X direction, and from -yrange to yrange in the Y direction.

 

But why do this and not use an orthographic projection for your 2D, and a perspective projection for your 3D?

Edited by Brother Bob
1

Share this post


Link to post
Share on other sites

By replacing my gluOrtho2D with gluPerspective, what changes shoud I make and where?


You also need to set up the modelview matrix.

After glMatrixMode(GL_MODELVIEW); you need some calls to glScale and glTranslate, to make sure your coordinates are scaled into the -1,1 range.

something like:
glLoadIdentity();
glTranslate(w/2,h/2,0);
glScalef(w,h,1);

Anything positioned on z-depth 0 can have the same coordinates as if they were set up in a ortho view.

You need to use different coordinates for your vertices since the coordinate systems are completely different. For a given vertical FOV and aspect ratio, you can calculate the range in X and Y direction at a certain depth Z.


They are only completely different if you choose to make them completely different.
(By for example not setting up the modelview-matrix.)

I'm assuming he want 2d planes in a 3d space, and feels it is convenient to use screen points to position those panes. Edited by Olof Hedman
0

Share this post


Link to post
Share on other sites

They only become equivalent for a very specific depth, everywhere else your scaling and offsets will be completely off.

0

Share this post


Link to post
Share on other sites

True, that is the point of a perspective transform after all. (give a visual queue of the depth by scaling things accordingly)

But they still aren't "completely" different, and doesn't have to be changed.

 

I assumed this is what he wants, for example to be able to do a 2D UI with nice 3D transitions.

0

Share this post


Link to post
Share on other sites

Yes, I assume that as well. But a difference in projection does not have to mean a difference in coordinates. With proper setup, he can indeed draw the same things and get the same result and that was the point of your and my reply. They are fundamentally different types of projection because you cannot blindly replace one with the other. The w and d in your code has to be calculated. That's fine, and the calculations is going to involve, in one way or another, the expressions I gave: w and d are going to depend on the FOV and the Z, and will only be valid for that particular FOV and Z. Your w and d are nothing more that compensation for the differences between orthographic and perspective projection.

 

He said he wanted 2D with layers, so your w and d, or my xrange and zrange, will necessarily have to be recalculated for each Z. An orthographic projection still allows layering and depth, but there's no need to recalculate anything for different depths, and the coordinate system can be directly and explicitly specified with the desired ranges. That is why I ultimately asked the question if his perspective approach is really necessary, or just based on the no-so-uncommon erroneous belief that your program cannot have multiple types of projections.

Edited by Brother Bob
0

Share this post


Link to post
Share on other sites
Yes, the end result is the same, its just a matter of where you choose to make the calculation... I just reacted to the statement "You need to use different coordinates for your vertices", since they don't strictly _have_ to be changed. specially not if all you want is transitions and movements in 3d, in that case you want the panel to grow if you move it closer, and shrink when you move it away from the xy-plane at z=0. vertices data can then be left untouched if the recalculation is baked into the modelview


He said he wanted 2D with layers, so your w and d, or my xrange and zrange, will necessarily have to be recalculated for each Z. An orthographic projection still allows layering and depth, but there's no need to recalculate anything for different depths, and the coordinate system can be directly and explicitly specified with the desired ranges. That is why I ultimately asked the question if his perspective approach is really necessary, or just based on the no-so-uncommon erroneous belief that your program cannot have multiple types of projections.

That is a good point, if all he wants is layering, an ortho view is probably easier.

I'm not sure what he wants from the original question, so hopefully he is properly helped now with our combined perspectives :) Edited by Olof Hedman
0

Share this post


Link to post
Share on other sites

Yes, that statement was not correct in that context and I even contradicted myself later, but it was more in the context of just replacing one with the other. Compensate properly for a specific case, and it works for that specific case: we both agree on that.

0

Share this post


Link to post
Share on other sites

Thanks for the replies.
 

I assumed this is what he wants, for example to be able to do a 2D UI with nice 3D transitions.



That's exactly what I want: be able to see my layers from different perspectives and choose one among them with a nice interface.

However, I couldn't make it work yet. Tried both approaches, from Bob and Olof, but stills nothing.

I don't know if I'm doing the calculations ok. Let me try to explain exactly how it's being done so far:

The layer l1 is drawn over the layer l2. Every layer have it's own attributes, i.e, xPosition, yPosition, width, height, and angle, so I must (I guess) apply the properly transformations in the modelview matrix before each draw.
 

As posted before, that's my perspective function, called before anything:


 

void setPerspective(int w, int h)
{
    glViewport(0, 0, w, h);
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    // gluOrtho2D(0, w, h, 0); (the old guy)
    gluPerspective(60.0, (GLfloat) w/(GLfloat) h, 0.001, 5000.0);
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    ... (transformations suggested by you)
}
 

 

 

And that's the mess with which my layer is drawn, working perfectly with ortho2D:
 

 

            glLoadIdentity();
            setPerspective(dst->width, dst->height);

               // Dest transformations
            glTranslatef(dst->cx, dst->cy, 0);  // cx = width/2   cy = height/2
            glRotatef(-dst->angle, 0, 0, 1);
            glTranslatef(-dst->cx, -dst->cy, 0);
            glTranslatef(-dst->x, -dst->y, 0.0f);

               // Source transformations
            glTranslatef(src->x, src->y, 0.0f);
            glTranslatef(src->cx, src->cy, 0);
            glRotatef(src->angle, 0, 0, 1);
            glTranslatef(-src->cx, -src->cy, 0);

            glBindTexture(GL_TEXTURE_2D, src->texID;

            glBegin(GL_QUADS);
            glTexCoord2f(0.0f, 1.0f);  glVertex2i(0,0);    
            glTexCoord2f(1.0f, 1.0f);  glVertex2i(src->width,0);  
            glTexCoord2f(1.0f, 0.0f);  glVertex2i(src->width,src->height);  
            glTexCoord2f(0.0f, 0.0f);  glVertex2i(0,src->height);
            glEnd();

            glBindTexture(GL_TEXTURE_2D, 0);
 

 

 

Edited by ak09
0

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
Sign in to follow this  
Followers 0