• 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
Tispe

Mesh in right-handed coordinate system, how to flip it?

4 posts in this topic

Hi

 

All my (shamelessly stolen from a game) meshses are upside down and rotated 180 degrees. This leads me to belive that the meshes are in the right-handed coordinate system. DirectX uses the left-handed coordinate system.

 

I have been rotating my meshes during transformation as a quick fix but I'm not quite sure if I should continue doing so.

 

I guess all the animation sequences are also Right-handed.

 

Now, is there any point in converting all this data to the Left-handed system during load time, and if so, how could I do that (vertices, textures, animations, etc)?

 

Cheers!

0

Share this post


Link to post
Share on other sites

would it not be better to import the model in the 3d modeling package that you use and do it that way ?, i think you didn't make the model by the sounds of it so you should be able to do it you're self ..

0

Share this post


Link to post
Share on other sites

I would expect handedness to show up with models appearing inside out, as the tri indices would all be wound backwards. It seems more likely that the handedness is the same, but the choice of world vectors in the modelling program is different than the one you are using. For instance, I generally think of y+ as up, and z+ as forward, yet blender which i use for modelling use z+ as world up. So at export time I must apply a 90 rotation to align my model so that it is good to go for my projects. If it truely is a handedness issue, then the solution is to invert 1(or all 3) of the coordinates(so point p(x,y,z) = p(x,y,-z) or similar), and swap 1 pair of indices per triangle(so that a triangle t(i0,i1,i2) = t(i0,i2,i1).

0

Share this post


Link to post
Share on other sites

I have been rotating my meshes during transformation as a quick fix but I'm not quite sure if I should continue doing so.

Uhm, No. You are just setting yourself up for some weird bugs that will eventually occur when you make a mistake. Which you will, eventually.

 

Trying to endlessly switch/convert between 2 different coordinate systems will just mess you up and may make you introduce a bug in a different class (or, and this is much more probable, in concatenation of the transf.Matrices), just because you are still focusing on coord.system.

 

 

Fix the problem right at the source - is the file in different coordinate system ? Then apply all the transformation right after you import the mesh so you don't have to worry about it anymore.

 

Do you have lots of meshes and don't want to do all those calculations at start-up ? Then , right after you import and transform to a correct coordinate system, save the transformed vertices and you will be 100% sure that coord.system is never the problem anymore.

0

Share this post


Link to post
Share on other sites


I would expect handedness to show up with models appearing inside out, as the tri indices would all be wound backwards.

Not really. He doesn't say anything about the Winding Order (clock-wise / counter-clockwise). That's a completely separate topic and issue altogether. Different gfx packages allow you to switch between them.

 

What's even worse is that different gfx APIs define the default backface culling differently.

Meaning -

1. INPUT : There is the first combination of Winding Order and Coordinate System of your gfx package (3dsmax,maya,softimage,blender,...)

2. OUTPUT: And there is the second combination of Winding Order and Coordinate System of your gfx API (OpenGL, DirectX, XNA, MESA, ...)

 

I would strongly suggest to take the time and Literally write down :

1. the Winding ordering for both input/output

2. the Coordinate system - EXPLICITLY - where each of the Positive halfspace is oriented  (e.g. Z-Axis towards the viewer, Y-Axis Up, X-Axis Right), for both INPUT and OUTPUT, directly into the source code for later reference. If you really think that you're going to remember it after 18 months, then you're in for a dissapointment.

 

 

 

While messing with the Coord.system, I strongly recommend to turn the culling off altogether and fix the Winding issue when the coord.system is taken care of.

 

Example : Importing mesh from 3dsmax into XNA.

- exchange Y and Z coordinate

- invert Z coordinate (due to XNA's coord system)

 

 

One more thing - a very common mistake is to forget to do the transformation on Normals and it may take quite some time to figure out something is wrong with the lighting ONLY under certain angles and make the connection to untransformed normals.

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