rendering time impacted by cameraviewport ?
Blitz3D Forums/Blitz3D Beginners Area/rendering time impacted by cameraviewport ?
| ||
| Hello, I was wondering if the rendering time of the 3d scene (with renderworld()) is impacted by the width and the height of the cameraviewport ? I suppose that yes because if there are more pixels to display, there must be more calculations, but i am not sure about what are the calculations involved for 3d rendering. Thanks, |
| ||
| I would imagine but its different between rendering engines how they handle viewport and rendering. Have you tried between not using viewport, one and multiple? |
| ||
| In the old days....the time.when blitz waa young and common cards were the 32MB TNT2 things like fill rate were very important. The things to keep in mind are: Complexity of scene. ...ie number of tris rendered. And how much overdraw. ..ie overlapping triangles. Also large triangles that occupy the entire screen especially when alphaed used to affect performance. Been so long since I've dabbled in 3d I can't say whether these remain true. |
| ||
| @Matty>>from my tests, overdraw/overlapping triangles is still a thing to avoid to prevent slowdown, even on recent enough graphics cards (2012) |
| ||
| In the days of quake 3, with my old low end computer, i remember that i was able to play with 800x600 but not with 1024x768 because the fps was too low. So i think that the size of the camera viewport must have an impact on the rendering time. |
| ||
| It's a possible bottleneck. More pixels to push means more work for the graphics card to do, simple enough. However, a modern graphics card can work on a lot of pixels at once, and B3D doesn't really ask it to do very much (mainly because of the lack of shaders). So that means that even if it's technically doing more work in some situations, it may have zero measurable effect on your program's performance because the work being asked of the graphics card probably falls well below the amount of work happening on the CPU and running at the same time, on a modern machine. Amdahl's law then kicks in. Blitz3D does the vast majority of its work on the CPU and has no way to offload it, so most of the performance improvements you'll see on a modern system will come from scene design. The thing to remember when looking for performance problems is to profile your program in as small chunks as possible. Multiple nanosecond counters throughout the frame, rather than a single FPS monitor. |
| ||
| @Yasha>>Currently i use the milliseconds time to determine approximately the time that a particular procedure function takes. Is there a way to access the nanoseconds time ? My question is because i am doing some experiments with artificial intelligence, and one way to check if a part of a target is visible is to use linepick and pickables (the target, the obstacles), but another way, already discussed on this forum, is to color the target in one color, to color the obstacles in another color, to position rotate the camera like the bot eyes position orientation, to define a small cameraviewport, to render the essential things in the scene (the target and the obstacles), then to check if at least one pixel of the small render has the same color than the color of the target, a kind of bot sight. |
| ||
You wouldn't actually want nanosecond resolution, that's far too precise to be useful. But you can get better-than-microsecond resolution with QueryPerformanceCounter and QueryPerformanceFrequency:.lib "kernel32.dll" QueryPerformanceCounter% (lpPerformanceCount*) : "QueryPerformanceCounter" QueryPerformanceFrequency% (lpFrequency*) : "QueryPerformanceFrequency" Counter returns the number of CPU ticks since program start; Frequency returns the number of ticks per second, which varies by processor and also processor frequency scaling, and should therefore probably be checked once per loop rather than just once at the start of your program. These take an eight (or more) byte bank or object as their out-parameter, through which they will return a long int result. |
| ||
| Actually I think blitz has or had a native high resolution timer....there waa5 a command to check the current scan line. Kind of a way of doing it. |
| ||
| It's been my sad observation that a newer gfx card makes a HUGE difference. Just had to add... |
   |