GUI, data loading, rendering

1. Your first idea is the way it's done. (it's much more "effective" (at least in coding and neatness) and much less "lame" than your second idea IMHO. And it's harder to make the second solution "pixel perfect")

2. You don't need multithreading, you can refresh/update/redraw the screen in the loading functions too. But multithreading may be a better/neater option.

I would like to ask how to make user interface and 2D graphic in most effective way. Should I firstly render 3D scene, switch to projection scene, set ortho and then render 2D graphics? Is this lame/ineffective?

I'd first set perspective projection then render the 3D scene, not the other way =P But yeah, this is the proper way to go, less hackish, no need to mess with the depth buffer, no risk of bugs. Use the alternative only if you're dealing with some stubborn API that won't let you do proper 2D, and that's a last resort.

[font="Arial"]Hi all,
I have some questions about GUI/HUD, data loading and rendering.

[color="#333333"]1. GUI/HUD
I would like to ask how to make user interface and 2D graphic in most effective way. Should I firstly render 3D scene, switch to projection scene, set ortho and then render 2D graphics? Is this lame/ineffective?
Second option is to render those 2D items as rectangles and then rotate/translate them depending on camera position.
Whitch of those two ways is more suitable? How do you render user interface?

2. Data loading.
I my project a want a nice "loading" screen. How do you implement dynamics of loading screen elements?
My first solution is to split rendering and data loading into two threads. Is it a good solution/what is your oppinion?

3. Rendering
Basically I am searching for optimal solution of concurrent rendering and data processing/event handling.

Thanks for all your advices, solutions, replies.

[/font][font="Verdana, Arial, Helvetica, sans-serif"][/font]

1. I prefer the first option.
3. There's no optimal solution, it depends on your engine design. In my engine I use job lists similar to the job lists in idtech5(google for "id tech 5 challenges"). The basic idea is, that you have multiple threads (=worker, one per core) and lists of jobs. A worker takes and process a job from a job list until all jobs has been procceed. You put your jobs into more than one job list to handle some simple signal-wait syncronization.

The really tricky thing about these jobs is, that you dont want to manipulate shared data, because you want to avoid synchronization mechanism (mutex etc., too many are really performance killer).

Here's a basic job overview from my engine:
1. one render job
2. many animation jobs (=>buffer)
3. one physics job (=>buffer)
4. many path finding jobs (=>buffer)
5. one fluid calculation job(=>buffer)

Still there're some synchronsation at the start of each frame, most jobs writes to a buffer and this buffer will be swapped at the start of each frame. Then there's the problem of the AI which manipulates lot of data (i.e. movement influences animation,pathfinding,rendering and physics, lot of events etc.), so the core AI is still a single threaded process.

Thought there's always a secondary level of "multiprocessing". When you call a render API the commands will be queued, the video hardware will process it with its own pace. So after your rendering engine filled up the command queue, the CPU can continue to do other things while your GPU is still rendering. This timewindow is used to do my single threaded AI. The basic framework looks like this:

>>frame start
swap all buffers (including the video back buffer)
collect jobs
start job processing (rendering,phyiscs,pathfinding...)
wait until all jobs has been processed
do AI (while GPU is still rendering)
<< frame end