• Create Account

# JoryRFerrell

Member Since 14 Oct 2012
Offline Last Active Apr 24 2013 06:36 PM

### In Topic: File formats which export texture mappings from 3d CAD software?

01 April 2013 - 05:36 PM

I'm not quite clear what you mean by "texture mapping". I presume you mean the texture coordinates (UV coordinates) that define how the texture is mapped to the surface of the model?

If so, pretty much every 3D model format supports them.

Well.....EMBARASSING. I overlooked how the texture coords are stored in obj file. I expected coords to be in .mtl file, not .obj.

NEEEEEVEEEEEEERMIND.

### In Topic: Determine if vert normal moves into or out of geometry by finding if verts cw...

22 March 2013 - 06:01 PM

I figured out a method and posted a vid on it:

### In Topic: Determine if vert normal moves into or out of geometry by finding if verts cw...

19 March 2013 - 02:11 PM

note:
usually figuring out the vertex normals is done (in the simple case) via a cross product.

say, we have 3 points (A, B, C) along the edge of a polygon, and want to find the normal for point B:
X=B-A
Y=C-B
Z=normalize(X % Y)

then basically, similar is done for each vertex, to generate starting normals.

note that depending on the winding of the vertices, the normals will either point into or out-of the object.

while this works, the normals generated tend to point directly out of the face, and ignore adjacent faces. for some tasks, we might want weighted normals.

the trick is basically for each vertex, finding any other vertices at the same coordinates.
then, one can do a "weighted average" of all the normals, with the weight being the dot-product between the normals.
this will smooth out soft curves while also preserving sharp edges.

dunno if this helps...

Yea, I already know about cross-product method. I have made one, but Newell's Method is more accurate.

Like I was saying, my method grabs all neighboring verts, and forms a projected face from them on each axis. For each created face, I find the normal of the face via the cross product method. Then with all those calculated face normals, I take the average and I end up with the more accurate per-vertex normal.

My problem was correctly finding the neighbor vertices in a consistent clockwise/counter-clockwise order. They often get reversed with my current algorithm. But, if I could find a way to correctly determine the order of the verts after finding them, I could simply reverse the per-vertex normal whenever it was facing the wrong direction. However I found a way to ensure the normal is facing the correct direction no matter what, and I don't need to determine the handedness of the neighbor verts order to do it. Look at explanation below.

### In Topic: Help learning how to structure code efficient and flexible

16 March 2013 - 12:16 PM

Only that which doesn't change can ever be perfect.

Make mistakes. Learn from those mistakes. Make new mistakes and learn some more. I get caught up in the idea of perfectly beautiful code a lot too... granted I'm slightly ocd. Like learning another (speaking) language you're far more likely to learn threw use of that language.

Beyond the vague. A blank piece of paper and pen do wonders for me in visualizing and keeping track of my original idea. I have one of those 2 inch thick notebooks for each of my projects. And a filing cabnet full of them. Before I code I tend to let my brain puke all over it. I find it the fastest and easiest way to get my ideas out. Granted I tend to close it and tbrow it behind me right afterwards then code. But I find Ok write less hackish code...

Its fun to scan over some of my old ones just to see how I thought about programming years past. I had a lot of bad techniques that make me cringe now a days ;)

Keeping things clean is usually a result of me going back over code and actually cleaning it up. Getting the code done and working is more important to me though.

I do the same thing with pen and paper.

There is something different about HOLDING a set of physical objects and solving the problem with them, that seems to make problems less complex.

Makes sense considering how the brain works I guess.

### In Topic: Help learning how to structure code efficient and flexible

16 March 2013 - 12:13 PM

Hello, I'm new to game programming and new to this forum.

I try to look through the forum, the books and the articles, but the content is so vast that I could not find what I was looking for. My background is PhD in physics and all my programming skills are through my education. I'm not a great programmer and for this reason i started playing around with game make studio, because it seemed simple. I've watched a lot of tutorials on youtube and read some articles and I think I've got the basics down. I want to make games in my past time and not professional and I think I will do it as a one man thing, at least in the beginning.

Now to my problem. Whenever I try to start making a game I loose the overview of the game. I simply don't know how to make efficient structure of the game. That is what to put where, should i use the build in physics engine, should i write something my self. What code should be put in the objects what should be put in scripts, and the list goes on.

All tutorials I have found are very basic, so if a tutorial says it will show you how to make a platformer, it will show you how to make a solid object and a player you can control. I can do that, however my code is very messy and not very flexible. So if I suddenly want to integrate for example a level up system for the player, it will be very difficult. Another example, I can make a player that can shoot and kill enemies, but if i want to add the possibility to change weapons, again it gets very messy.

I hope someone can help me to learn writing efficient, flexible and smart code. In my head it would be very nice if i could write single modules, and then combining them to a game. And also latter easily add a new module if i get a new idea, without having to go through all single objects implementing this new module. Don't know if this is possible. Hope my problem is clear, or else write and I will elaborate.

So to summarize I don't need help learning to program specific code (I learn on the fly, using google and the help file), but help to build the complete structure and combining the individual code efficiently.

Ant type of help would be appreciated: books, webpages, youtube, direct guidance ...

I have the same problem. You need to study everything as a building block. You have a phd in physics so that shouldn't be hard.

Pretend you are playing with lego's. The entire structure can be complicated as a whole, but broken down, it's pretty simple. In fact,

once broken down to the individual blocks, the mechanics behind the build are pretty intuitive. Unfortunately the building blocks of

programming languages are not as simple as lego's, but once you start learning to keep looking at the basic blocks, you start to

intuitively get a better grasp of whats efficient and what isn't. It's easier said than done, but this IS the way to view it.

Start by learning the  basic types and the general do's/do not's on how to use them. Then use those blocks to build a small, tightly

packed (i.e. efficient) larger lego structure. Now that you have that efficient block put together, you can stop looking at the

underlying specifics behind it every time you need that function, and use it to build and even larger lego structure made up of other

tightly packed, pre-structured code. Now again, easier said than done. I have  learned that you will eventually hit parts of code

where it seems so abstract and non-straight forward, like a dot product can be, that it's hard to find an efficient way to string

together blocks into an efficient struct. It's the same in physics. It's easy to calculate gravitational effects on a baseball thrown

in an arc on earth. It's not so simple to calculate the effects on a baseball thrown into a binary-blackhole system. Sometimes

you'll just run into problems that seem so abstract and removed from a certain paradigm you are use to working on, that it will just

be a mother*******. But remember:

KISS.

Keep. It. Simple. Stupid.

I constantly have to remind myself of that. I'm extremely tired, and still, I have to retrain myself to break things down like this

no matter how tired or discouraged I am. Once you train  to the point that you start noticing that programming certain types

of problems efficiently becomes intuitive, you'll be more motivated and actually possibly come to enjoy sifting through some

forum posts, which were seemingly inane previously, on how to improve this algorithm or that. Patience is a big factor. I am

no where near expert, but I have noticed the more time I invest in the basics instead of trying to skip ahead and make

something, the more I just naturally understand. Having a high level degree, you have already experienced the kind of

pace you need to think at when programming. It's long term, methodical work. And as usual, it's best to not try to cram

overnight before the big exam. No one writes a Far Cry 3/Battlefield 3 overnight, especially not as a loner, fly-by-night

programmer. The more methodical and slow your approach at programming in the beginning, the faster you will actually

begin writing better code. Also, don't forget to do back-research. You should have some understanding of different os

platforms since each handle windowed apps differently (unless you use scripted languages which are often able to handle

much of the thinking there for you). You also need knowledge of your individual compiler, and os file system/path

requirements.This is currently annoying the hell out of me. I have been fooling around with python seriously for the past

year, and I just started earnestly trying to learn C++. C++ requires all kinds of weird linked in file types and organization.

The IDE/compiler alone feels more complex than any of the C++ programming concepts themselves.

But again, that's because I naturally slip back into viewing the IDE as a whole rather than it's simple pieces. KISS. Lordy KISS,

KISS, KISS.

In short:

- Learn the general overview of the problems you need to solve. Then find out the basic starting points you need to

start solving the smallest problems. You can't solve 3d rotation without trig, and you can't figure out trig without

understanding basic arithmetic.

- Remember to break the whole problem into manageable pieces that you easily, and intuitively can solve. Those then

combine with the other smaller pieces you have already solved.

- Keep reminding yourself to not throw yourself headlong into a brickwall trying to solve the problems immediately.

It causes undue stress, making the problems even harder to solve. If you are apt to doing this out of your very nature

as I am, I feel sorry for you because I know what you are in for. But again, keep working at it, while just taking up

the additional task of purposefully, and intently, retraining yourself to break this habit and remind yourself of the

mindset needed to solve the paradigm at hand.

Have fun. Once I get the initial roadblocks out of the way, I know I will be doing so.

PARTNERS