opengl: moving the light with level

**Darkness** · 04-05-2005

That's fine and dandy, if you know how to implement these things. If you're still learning, the worst thing you can do is worry about speed when you don't know the concepts. Everybody that I know of working on large successful projects follows the code first optimize later scheme. What happens when you try writing a large project while trying to 'optimize' first? This:

Originally Posted by Bubba

In fact I'm going to totally re-do the entire engine because I'm not happy with the current architecture and I'm not happy with the current code base.

It needs a complete facelift and rather than try to edit existing code, I'm going to change the whole setup.

But after spending 4 hours messing with MFC and having it totally erase my work because MS can't program anything remotely stable, I'm not really into coding right now. Heck I might just erase the whole frieking XSpace and start over.

Me, on the other hand, the last project I abandoned was huge (as in I haven't been coding in the last year), at over 20,000 lines of code (C-Metrics) but it was modular, easy to follow and edit by others, and I was satisfied with its layout (it took care of a plethor of things including 3D rendering based on binary and quad spatial partitioning, culling, sphere and box physics, basic realtime lighting, basic static lighting, and hooks for vertex buffer objects and fragment/vertex shaders), and I wrote it entirely on the 'code first, optimize later' mechanism. I guess I don't need to mention the doom3 alpha basically wouldn't run on even the fastest computers, suggesting they also followed the code first optimize later scheme.

But, we all ultimately find what works best for our individual needs.

**Perspective** · 04-05-2005

>>What happens when you try writing a large project while trying to 'optimize' first?

I didnt say optimize first. I said design first. You can always go back and optimize later, but if you start with a poor design there's not much point.

What happens when I try writting a large project? The current project I hack on at work has about 2.5 million lines of code. We desing first, then implement, it works great

>>Me, on the other hand, the last project I abandoned was huge (as in I haven't been coding in the last year), at over 20,000 lines of code

well, i guess that depends on your definition of *huge*.

**Darkness** · 04-05-2005

Of course you are going to have a design first.

You seemed to imply basing your design around optimizations. Hence my comment about worrying about the slowness of real time lighting when the OP doesn't even know how to properly position a light. If you worry about optimizations when you are making a design, it typically goes bad, simple as that.

What 3D company do you work for and what types of 3D applications do you work on?

**VirtualAce** · 04-05-2005

*slaps forehead* didn't your mom ever tell you not to worry about speed until you've got a working implementation?

This will get you into a mess in a hurry.

Quote:
Originally Posted by Bubba

In fact I'm going to totally re-do the entire engine because I'm not happy with the current architecture and I'm not happy with the current code base.

It needs a complete facelift and rather than try to edit existing code, I'm going to change the whole setup.

But after spending 4 hours messing with MFC and having it totally erase my work because MS can't program anything remotely stable, I'm not really into coding right now. Heck I might just erase the whole frieking XSpace and start over.

Since you feel at liberty to discuss things about my engine I will explain. The architecture needs to be changed so that I can load everything from disk instead of create it on the fly from mathematical geometry. It also needs to be changed so that one render function can render the entire world. Right now it is using an object-based render setup where each object is responsible for rendering itself.

There are several things you must optimize in Direct3D programming:

1. Only call SetTexture() when it is absolutely necessary.
2. Change render states as few times per frame as possible.
3. Only call SetTransform() when it is absolutely necessary.
4. Render all primitives in huge batches.
5. Use one huge global vertex buffer that contains the entire scene, also with triangle-strips applied to areas that they can be, and render the entire scene from that buffer.

Many of these seem simple but they are not...but they are the key to gaining a lot of performance under Direct3D. The SDK has many more optimizations as well like geometry caching and other hard to implement schemes.

I will tell you that if you just jump out and code you will code yourself into a corner. You must design and you must at least have something in mind about what performance you want or you will never get it. You know how hard it is to change a rendering system from object-based to then using a global vertex buffer and having everything in it? Extremely difficult. It would have been better to design a global vertex buffer and render from it from the beginning - again design is important, but design with a purpose and with a goal.

You can't just throw some DX code together and expect it to work and be applicable in all cases. It just doesn't work like that. Sure, it might work, but it's not extensible, it's not fast, and it creates more problems than it solves.

**Perspective** · 04-05-2005

>>What 3D company do you work for and what types of 3D applications do you work on?

3D graphic programming is my hobby. My programming at work has nothing to do with graphics.

**VirtualAce** · 04-05-2005

And I'm the biggest loser of em all because I don't even program for a living. I do all this stuff for 'fun'

Sick eh.

**Darkness** · 04-05-2005

I did this for about four years solidly (i.e my high school years). I got really good at it and had the intention of being a game programmer, then I just decided I don't want it or school and now I'm joining the military

**bluehead** · 04-05-2005

heh

the great thing is. I've been programming since 6th grade. But i was too stupid to understand the concepts of any of the newer, more advanced things (like opengl/window programming) so i never got to it.

i program as a hobby, too, but some money motivation would be great... once i get older, of course.

so, quickly back on topic for a second
~would the light move the same as the whole world does? as, following the glTranslate i use for the world? or do i have to do it differantly

**Darkness** · 04-05-2005

Yes, you apply the same transformation to the light as you do to the world

We made a lot of posts to get that simple point across, lol

edit:

yeah, a lot of the math stuff in GL is pretty hard. And windows programming, well, it takes a lot of arcane winapi crap just to get a friggin window up that you can draw to.

**Tronic** · 04-13-2005

Gah, if the WinAPI wasn't so freaking intimidating to make that window I'de bet you money that there would be more OpenGL programmers.

Personally I do programs in three steps:
1) Draw my design plans
2) Assign a weight to each module of my design
3) Rearrange / change the type of module I'm using to make the smallest total weight.

Coding doesn't fall into this since when I code I do both implementation and first/second phase optimizations when I code. All other optimizations I would need / would benefit from are usually from me skimming over my mistakes I try not to make next time. Usually programming this way has always been better for me personally, time, money, and confusion wise.

Thread: opengl: moving the light with level

Thread Tools

Search Thread

Display

Similar Threads

Critique my lighting model.

OpenGL Window

geometry won't display!?

OpenGL .dll vs video card dll

MISC questions about OpenGL