ObjReader Community
WIP => WIP => Topic started by: Michael Lobko-Lobanovsky on January 24, 2018, 06:35:17 pm
-
My attempt was to render the scene to texture in either FFP or PPL for subsequent post-processing with various effects shaders, and then finally render the post-processed screen-sized textured quad onto the screen for viewing.
The technique sort of works... However,
the resultant texture seems somewhat imprecise as if it were transparently resized by OpenGL, which obviously causes extra jagginess and loss of fine detail; [UPD] Resolved. Currently the details are actually even sharper than they should be.- the cost of glCopyTexImage2D() in each frame appears too high for practical purposes with high poly models (poly count > 1M).
Below is an example of vignetting an FFP render with a post-processing shader.
( :-\ ) ;)
-
Hehehehe... :P 8) :D
In fact, the vignette shader allows for very simple and easy scene over-brightening. It's effectively the missing upper half of ObjReader's "stray light" control. :)
-
Not bad for starters, n'est-ce pas mon ami? :)
The 2D effect is the same as in my earlier "fake light shafts" demo featuring a picture of Regent Street in London. The screenshot was taken while in the FFP mode.
-
Patrice,
I think we have reached the limits of what we can do in the context of ObjReader's current camera, vertex buffer array storage and render target utilization:
- Keeping vertex/normal/texture data in multi-million poly RAM-resident arrays we're binding to the OpenGL default render target (color buffer) in each frame stresses the data bus, and especially so in the animation (continuous-render) mode(s) of operation.
- The only technique we can utilize currently for post-processing is the so-called "render-to-texture" method, which is effectively deceptive in terminology. In reality, we're still rendering to the color buffer and then we have to copy the color buffer contents explicitly to a real texture with a call to glCopyTexImage2D(), post-process that texture, and then apply it to the screen sized quad for rendering into our on-screen viewport. glCopyTexImage2D() proves to be such a heavy stress to the GPU that whenever I try to rotate my model (regardless of its complexity) or drag it across the screen, let alone animate its rotation, both my GPUs go up to 95%+ load.
- It may be not so obvious at a first glance but no matter what we do with our current camera, we aren't able to access at least one third of 3D space and its perspective we're "seeing" on our monitors. We aren't able to tilt (in fact, "roll") the camera around the world's Z axis. For the people who are aware of what's going on on their screens when they rotate a model, it's an annoying and massively stressful factor.
My proposal is as follows:
- Instead of vertex buffer arrays (VBA's) we henceforth shall use vertex buffer objects (VBO's) that are effectively VBA replicas in the GPU video memory. Once uploaded on the GPU, VBA's may be safely freed. They aren't going to be pumped along the data bus any more. VBOs are toggled directly on the GPU, and the resultant bandwidth (in other words, the model size and/or equivalent FPS rate) may increase several times.
- Instead of color buffer and "render-to-texture" we henceforth shall use the frame buffer object (FBO) that's effectively a kind of texture in the GPU video memory bound transparently as a persistent render target. The FBO supports all features of a real texture and as such wouldn't require extra stressful glCopyTexImage2D() calls. The FBO can be rendered to, post-processed, and mapped to the on-screen quad directly.
- The entire camera code shall be re-written from scratch maintaining clear track of separate model, view, and projection matrices for every minute transformation of camera-to-model spatial orientation. This is to allow for easier and faster calc of distances, parallaxes, and mutual orientations of scene objects/meshes for more precise visibility clipping, dynamic alpha sorting, collision detection, etc. And it will make integration of shader code from different sources considerably easier too.
To this end, I am going to abstain, for the time being, from active development of the current version of ObjReader and engage myself in writing the skeleton of a new ObjReader implementation from scratch. Once the newer technology features described above prove to be working, you will take over, skin the app and merge your other GDImage goodies with the new implementation, and we'll enjoy a brand new ObjReader v3.0 that's up to date with modern OpenGL.
If we don't do that now, we'll keep on looking as two archeologist old farts digging in the remains of ancient immediate mode OpenGL civilization for the rest of our, alas, limited lives.
If you agree to my proposal, then also let me know if you can stand OOP implementations of certain parts and features of new ObjReader code, e.g. vector and matrix classes and maths and the like. I'm going to work directly in C++ omitting my usual FBSL ANSI C stage. I will try to follow the existing ObjReader's general layout but that certainly isn't going to be my primary goal or pattern. Speed and usability is what's in fact going to matter in the first place.
This doesn't mean you should likewise abandon your WIP on v2.0 or its beautiful 3D content and retire in your audio/video apartments. Everything that you have at hand by the time the v3.0 skeleton is ready will find its due place in the new code too.
-
My friend,
Who am i to tell you what to do.
The only thing i can say, is that i have a very limited knowledge of modern OpenGL programming. And so far i have done the best i could do with my expertise, meaning that i couldn't help, but only learn from you if you switch to this new paradigme
The very first version of this wavefront reader i started from, was written using OOP, and the first thing i did was to convert it to the procedural mode i have ever used, that says all... ;)
Starting to write version 3 from scratch, is probably the best way to experiment with new features, rather than having to deal with the existing code.
I shall keep working on the interface of version 2 to make it more user friendly.
And rework or work on new 3D model(s) to provide a good food for our renderer.
-
Great!
- Probably I didn't make myself clear enough in my proposal. Our new VBO/FBO rendering strategy is not going to eliminate the immediate mode capability:
- We will be loading vertex/texture/normal/tangent/bitangent data into the VBA's as we did before. But we will not bind them to the OpenGL render target directly from the system RAM in our render procs. Instead, we will additionally upload them on the GPU for permanent storage in its video RAM in the form of VBO's and then we will free the VBA memory because we won't need the original VBA's any more. Thus we will eliminate pumping the model geo data along the system data bus in each frame render over and over again.
- OpenGL's default render target (color buffer) will be substituted with our FBO that supports all features of a custom texture, allows direct writes at render and post-processing times, and can be bound to the screen sized quad directly as a texture to finally render the scene onto the screen. The sequence (and purpose!) of OpenGL commands in our render procs is going to be pretty much the same as it is now. It is only the names of OpenGL functions that are going to be a little different.
- It is irrelevant for the VBO's and FBO if we draw using immediate mode commands (FFP) or advanced GLSL shading (PPL). They will work for the both -- but much, much faster and more precise than my current "render-to-texture".
- I will try and keep the number of new OOP classes to the absolute minimum -- just 3D vectors, 4x4 matrices, and probably the camera itself. The ability to use overloaded operators in object-oriented vector and matrix maths is a blessing as compared to procedural C operations on raw floating-point arrays. Aren't you happy with using std::strings in your own code after all, my friend? ;)
You aren't going to be thrown overboard, Patrice, no way. Your expertise in immediate-mode OpenGL is going to serve us well into the future. :)
-
Aren't you happy with using std::strings in your own code after all, my friend?
All std::strings has been removed from my latest creations, i keep using them only inside of my first PB to C++ translations like ObjReader. ;)
Since then, i am using my own WCHAR subset fo the purpose of reducing the size of my binary dependencies. ;D
But i am not obtuse, and i can live with a little OOP.
However i will always bypass the GDIPLUS class, and keep using the flat API that serves me well since 2002 8)
-
No FBO for post-processing nor new camera yet but
!!! VBO's are already there !!!
8)
:D :D :D :D
( [UPD] My continuous render-mode default-size window GPU is ca. 40% but CPU and data bus are 0% overall. It's effectively nil, null, naught; an immeasurable infinitesimal! Rotation is perfectly smooth as if there were just a couple of polies to render... :) )
-
Well done my friend !
I thought you were too busy on other tasks, and that you have moved VBO/FBO onto your back burner :)
When playing with large models, like "Event Horizon" or "AB" i sometimes see some of the meshes not being displayed.
I wonder if the changes done into calcMeshBounds() and isSphereInFustum() could explain this ?
With AB sometimes she loose her shoes or her bandana :)
While running in full screen mode, i would like to add some more handy informations into the SL display, like the CPU and GPU % charge.
Do you know if there is some easy way to retrieve these values without hogging the CPU ?
Added
Does that nVIDIA GPU % would work by you?
//
// Getting Nvidia GPU Usage
//
// Reference: Open Hardware Monitor (http://code.google.com/p/open-hardware-monitor)
//
#include <windows.h>
#include <iostream>
// magic numbers, do not change them
#define NVAPI_MAX_PHYSICAL_GPUS 64
#define NVAPI_MAX_USAGES_PER_GPU 34
// function pointer types
typedef int *(*NvAPI_QueryInterface_t)(unsigned int offset);
typedef int (*NvAPI_Initialize_t)();
typedef int (*NvAPI_EnumPhysicalGPUs_t)(int **handles, int *count);
typedef int (*NvAPI_GPU_GetUsages_t)(int *handle, unsigned int *usages);
int main()
{
HMODULE hmod = LoadLibrary(L"NVAPI64.dll");
if (hmod == NULL)
{
std::cerr << "Couldn't find nvapi.dll" << std::endl;
return 1;
}
// nvapi.dll internal function pointers
NvAPI_QueryInterface_t NvAPI_QueryInterface = NULL;
NvAPI_Initialize_t NvAPI_Initialize = NULL;
NvAPI_EnumPhysicalGPUs_t NvAPI_EnumPhysicalGPUs = NULL;
NvAPI_GPU_GetUsages_t NvAPI_GPU_GetUsages = NULL;
// nvapi_QueryInterface is a function used to retrieve other internal functions in nvapi.dll
NvAPI_QueryInterface = (NvAPI_QueryInterface_t) GetProcAddress(hmod, "nvapi_QueryInterface");
// some useful internal functions that aren't exported by nvapi.dll
NvAPI_Initialize = (NvAPI_Initialize_t) (*NvAPI_QueryInterface)(0x0150E828);
NvAPI_EnumPhysicalGPUs = (NvAPI_EnumPhysicalGPUs_t) (*NvAPI_QueryInterface)(0xE5AC921F);
NvAPI_GPU_GetUsages = (NvAPI_GPU_GetUsages_t) (*NvAPI_QueryInterface)(0x189A1FDF);
if (NvAPI_Initialize == NULL || NvAPI_EnumPhysicalGPUs == NULL ||
NvAPI_EnumPhysicalGPUs == NULL || NvAPI_GPU_GetUsages == NULL)
{
std::cerr << "Couldn't get functions in nvapi.dll" << std::endl;
return 2;
}
// initialize NvAPI library, call it once before calling any other NvAPI functions
(*NvAPI_Initialize)();
int gpuCount = 0;
int *gpuHandles[NVAPI_MAX_PHYSICAL_GPUS] = { NULL };
unsigned int gpuUsages[NVAPI_MAX_USAGES_PER_GPU] = { 0 };
// gpuUsages[0] must be this value, otherwise NvAPI_GPU_GetUsages won't work
gpuUsages[0] = (NVAPI_MAX_USAGES_PER_GPU * 4) | 0x10000;
(*NvAPI_EnumPhysicalGPUs)(gpuHandles, &gpuCount);
// print GPU usage every second
for (int i = 0; i < 400; i++)
{
(*NvAPI_GPU_GetUsages)(gpuHandles[0], gpuUsages);
int usage = gpuUsages[3];
std::cout << "GPU Usage: " << usage << std::endl;
Sleep(250);
}
return 0;
}
-
Well done my friend !
Thank you Patrice! :)
I thought you were too busy on other tasks ...
I am from time to time, but it doesn't mean I'm out or I ain't interested any more. :)
... i sometimes see some of the meshes not being displayed ...
Not any more my friend, not any more! Probably you wouldn't believe me until seen with your own eyes but now flipping/dragging "Event Horizon" or "AB" vigorously across the screen is as easy as a piece of cake, as if they were my Q3Torch or your first OpenGL colored triangle application. :D
... calcMeshBounds() and isSphereInFustum() could explain this ?
Mesh visibility is indeed controlled by isSphereInFustum() but the artifacts are exclusively due to data bus stalls. The CPU is still waiting to calc it at a new mouse pointer position while OpenGL has already drawn the scene. OpenGL swaps its buffers in a parallel thread out of sync with the CPU regardless of glFlush/glFinish. My AB would usually lose her sunglasses and a coupla Cokes but never her Mars pack. ;D But not any more!
i would like to add some more handy informations into the SL display
Sounds like a great plan!
... easy way to retrieve these values without hogging the CPU ?
Just use your "nVIDIA GPU %" and a standard CPU % process counter lookup routine. They aren't going to hog anything if taken once a second. You would even have a chance to draw your own history graphs ( 8) ) without any visible impact on the IPS/FPS rate. I have also moved all function calls completely out of our render procs except the visibility check and pure OpenGL proper, so that the procs are just as fast as they can only be in C code without inline asm. 0% CPU on Onyx, Patrice, and I really mean it!
Does that nVIDIA GPU % would work by you?
Of course it does! Tell you more: I also own a full AMD/ATi Radeon based box running under x64 Windows 7 that's able to cope with ObjReader as well. So if you could find a similar routine for use with a basic ATi GPU driver, we would go real cool with ObjReader's GPU auto detection. (don't forget to reserve some space for small and neat nVidia/ATi icons ;D )
Now, can you wait a couple of days more until I get FBO up and running too before I send you my mods? The new camera will come the last.
-
Brilliant!
Re: GetSystemTimes()
That's cool but more suitable for a profiler. But there are also process counters accessible through the Windows registry IIRC that would yield per-core and total CPU load readings in real time as they are depicted in the Windows Task Monitor. Would be cool to have those too to match the GPU readings. :)
Any luck with Radeons yet?
-
I had fun, thank you very much for this preview.
Here is what i get on my computer using "Event Horizon"
IPS 33 (perfect)
CPU 0% (perfect)
GPU ranging between 27 and 52%, and most of the time at 32%
Mesh visibility problem is still there, see the attached screen shot.
I have disabled isSphereInFrustum in my current WIP, i shall see if that makes any difference once i am done with my current work on CPU/GPU display (visible only in full screen mode from the SL display).
I think that this new version will be a killer's one ;)
Any luck with Radeons yet?
So far i haven't found anything, but i did just a quick search...
-
GPU ranging between 27 and 52%, and most of the time at 32%
In fact, that's very good. All activity now takes place on the GPU as planned. There must be something working at full thrust after all; there's so much to be done in each frame render especially on such a huge model as that.
Mesh visibility problem is still there ...
It's related to the inexactness of bounding sphere radius projection calc, very similar to my PITA with the initial versions of AA billboards. The longer one of the axes is relative to the two others, the larger the error. I'm hoping to see it cured in the upcoming camera though. That's one of the main reasons I've been advocating it in the first place.
... i shall see if that makes any difference ...
Oh yes, it does, and especially in a multi-mesh model with complicated geometry. You don't need counters to prove it. Just listen to your GPU fans and watch the jerkiness of your mouse movements. ;)
... once i am done with ... CPU/GPU display ...
That won't be too soon. I have my own idea of usefulness and content of such a display. ;) And I'll look into the ATi Radeon capability myself.
I think that this new version will be a killer's one ;)
I hope so too. I'd love to see it doing all that it presumably can. :)
-
Below please find my precompiled WIP ObjReaderVBO.exe. Its distinguishing features are:
- isSphereInFrustum() is currently disabled not to irritate you till it's perfect. But be forewarned that eventually it will be there or I'll quit this project! :D
- gl_DrawScene() is now yet substantially faster because its entire glBlaBla() intro has been precompiled in a draw list.
- Whenever applicable, all turtle slow sqrtf(), 1/sqrtf(), fabs(), fmod() occurrences have been substituted with their much faster integer math approximations. Tell you what my friend: in fact, OpenGL needs only as much as half-float precision. All extras are but unpardonable squander. ;)
- Your IPS has been persistently off the point by 2 frames per second on low FPS counts. I've fixed that glitch though I'd still rather see it re-written to comply with industry tradition.
Enjoy!
-
The new VBO wip seems to work great !!!
Using Event Horizon
IPS 32, GPU average 30% , CPU average 3%
all meshes preserved ;)
See the attached video.
You did a tremendous work my friend...
-
Patrice,
It's just now that I got a bit of free time. Downloading and merging...
Works nicely, thanks a bunch! :)
([UPD] I'm currently revising the entire hardware.h; I have two nVidia GPUs working in parallel and I need a mean of two concurrent usages. The new ObjReaderVBO is attached below. Please let me know if its readings for your single nVidia GPU box are still correct.)
I am working on a stress test model with 17855355 indices...
We are going to have problems with our VRAMs soon. :)
All the verts and indices, as well as shaders and 8K textures and their mipmaps go there. When there isn't enough VRAM room for everything, the GPU starts to transparently swap parts of it into ordinary RAM. This is bound to seriously affect the frame rate.
GeForce Titans 1050+ are in extreme demand these days. Everybody seems to have gone bitcoin mining, and the prices skyrocketed dramatically. :)
-
I have found some C# code that collects GPU load data for ATi videocards. Surprisingly, ATi drivers are open source but there's no clear guide as to how to collect ATi GPU data. nVidia drivers are closed source but everybody seems to know how to squeeze the last bit of fan RPM and GTX GPU temperature data out of them. :D
Nobody knows what to do with Intel GPUs. They are absolutely opaque black boxes. ;)
Below is a snapshot of ObjReader running on my AMD box with an Athlon 64 X2 dual core CPU and ATi Radeon R7 200 GPU. As you can see, the CPU meter works (high load is due to the AV scanner running concurrently its scheduled task) but the GPU meter is yet dead. Hopefully it goes alive some day too. :)
-
Patrice,
Your "delay" calc in gl_TimerView() is mistakenly 2 ticks off the point, just as your IPS was in gl_DrawScene().
Watch the correct arithmetic and readings in action. Probably for the first time in ObjReader's history.
-
I am well aware of it, that was done by design, and this is the exact reason why i am using the word IPS rather than FPS:
The historical purpose of it, was to save the CPU. I am doing this also in BassBox, however in BassBox i have the High FPS option (see the attached screen shot, and the High FPS checkbox).
This allow my OpenGL (1.0, 2.0) multimedia applications to be more cooperative with the other running applications.
I had this in mind when i wrote the word new "overclocking" option (when using VBO), in one of my previous post ;)
Added:
You may read this about the DwmGetCompositionTimingInfo, because ObjReader/GDImage are using much DWM beind the hood, especially on Windows 10.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa969503(v=vs.85).aspx
-
Hehe, so your Easter egg has been spotted, isolated, and neutralized! :P
Seriously, I think we shouldn't fiddle with these tweaks. Using a Windows timer in a serious application is in itself a weird enough thing to do but tweaking that timer is a bit too much. If you want a half speed then VSYNC it traditionally to 30 FPS and be done with it. If you want decent 60 FPS then VSYNC it to 60 or adaptively. If you want full thrust and steaming GPUs then disable VSYNCing altogether and fry your omelette on your box' top cover. But all this fiddling with the timer does no real good and leads only to jerky rotations and stalls.
To cut it short, I fixed the arith in all the three places and renamed nIPS to nFPS, and "IPS", to "FPS". Rotation is smooth, and GPU%, bearable. And FPS and Fraps readings, equal. :)
-
Patrice,
Let's stop theorizing for a while and get busy with verification.
My readings are in the screenshot below. What are yours, svp?
(new ObjReaderVBO attached)
-
Here is mine, using exactly the same window size than your screen shot.
There is obviously a big difference... :-[
-
No wonder, your GPU is faster than mine.
We were talking about DWM: I'm observing absolutely no stress on the DWM subsystem in my screenshot.
Here are my readings on my Windows 10 box (it has my old pair of 8600 GTE geForces installed, hence significantly lower FPS but again no stress on DWM).
BTW Fraps works under my W10 like a charm; I don't understand why it isn't working for you.
My AMD/ATi readings will come a little later because ObjReader's ATi Radeon initialization code isn't ready yet.
-
And here's my AMD/ATi screenshot though ObjReader's Radeon code still isn't working. The GPU usage can be seen in the desktop gadget.
Again, DWM % is very low as is CPU. Frankly, I don't fully understand why we're talking about DWM at all.
As for me, the new ObjReader is performing pretty decently and especially so on your own laptop. So what should we worry about? ::)
-
BTW Fraps works under my W10 like a charm; I don't understand why it isn't working for you.
I could not find a link for W10, i have an old one, but it failed miserably on my computer.
As for me, the new ObjReader is performing pretty decently and especially so on your own laptop. So what should we worry about?
This version is light years ahead of any other players around, and it disserves a new major # (version 3.00).
Your work on VBO is just perfect for my ASUS laptop, you have got my five stars, no contest.
I am looking forward to see the source code ;)
Added
About DWM frequency, this one returns 75 by me, on my ASUS laptop.
void DwmFrequency() {
DWM_TIMING_INFO dti;
ClearMemory(&dti, sizeof(dti));
dti.cbSize = sizeof(dti);
if (DwmGetCompositionTimingInfo(NULL, &dti) == S_OK) {
LARGE_INTEGER Frequency;
if (QueryPerformanceFrequency(&Frequency)) {
float hz = (float) (Frequency.QuadPart / dti.qpcRefreshPeriod);
zTrace(STRF(hz));
}
}
}
-
Patrice,
My suggestion is as follows.
I'm hoping to get the Radeon usage code working today. When done, I'll send you the sources and we can release this build as ObjReader v2.5 Stable. We will be keeping it available for users even when working towards ObjReaderFBO w/ post-processing and other capabilities and we will be using it as a reference for our own progress.
When ObjReaderFBO is ready as v3.0, we will still be offering v2.5 for users with simpler hardware and undemanding needs of viewing .OBJ models in a decent viewer. At the same rime, my own goal is to keep on introducing more and more editorial features like lighting, cameras, simple animations, pre-/post-processing effects, etc. Possibly adding an own binary file format to keep these candies in the model file itself as .MAX, .LWS, .C4D files do, and also to make file sizes significantly smaller and faster to load etc. etc. etc........
I will also send you my Fraps installer. It's free to use and it works in 64 bits like a charm. It's still a 32-bit binary itself but it installs a 64-bit detour on the 64-bit OpenGL and/or DirectX drivers to be able to work with both bitnesses simultaneously.
-
i feel like an happy camper looking at the shooting stars during a dark summer night :) ;) :D ;D
-
In the VBO version replace the ips.png (both source code, and skin folder) with the new attached fps.png
Also, because you have switched to overcloking mode, replace
if (gP.rGiroStep == 0.0f) { gP.rGiroStep = 0.25f; }
with
if (gP.rGiroStep == 0.0f) { gP.rGiroStep = 0.125f; }
8)
-
... replace the ips.png ...
Cool! Done.
... replace if (gP.rGiroStep == 0.0f) ... 8)
I won't. First study my fixes, then replace if needed. :P
My VBO mods are attached below:
1. isSphereInFrustum() temporarily disabled not to irritate you for the time being
2. Multiple nVidia geForce usages supported
3. Single ATi Radeon usage supported
4. Intel GPU usage not supported yet
Please merge your most recent mods, if any, with my base code, re-compile, and let me know if it works fine for you.
P.S. Would love to see one or the other of those (or similar) icons somewhere to indicate the current GPU.
-
I won't. First study my fixes, then replace if needed.
Are you aware that you can adjust the speed with the "+" or "-" key
the FPS being twice the IPS, gP.rGiroStep must be half its previous value, to keep the smooth small step i have used by design.
If you find it too slow just, press the "+" key.
We could also add of a new preference setting to save the user choice ;)
-
Mike
Ok, i did further test, and with half the speed (IPS) then the mouse is much more responsive.
This is the exact same problem i had years ago in BassBox, when using mouse interaction with some of my visual plugins.
You can check this by yourself if you try to pan the model like crazy with the right mouse button, using the current code.
Then make another test, trying with this:
if (AnimDelay == 0) { AnimDelay = gP.AniTick + TIMER_DELAY; }
//if (gP.AniTick >= AnimDelay) { // MLL 02-14-2018: else it's 2 ticks too much! 999 and 0 below makes 1000.
if (gP.AniTick > AnimDelay) { // IPS code
AnimDelay = 0;
gl_DrawScene();
}
//if (ReportDelay == 0) { ReportDelay = gP.AniTick + 999; } // MLL 02-14-2018: be consistent!
//if (gP.AniTick >= ReportDelay) { // MLL 02-14-2018: else it's 2 ticks too much! 999 and 0 below makes 1000.
if (ReportDelay == 0) { ReportDelay = gP.AniTick + 1000; } // IPS code
if (gP.AniTick > ReportDelay) { // IPS code
By me the difference is obvious, this is the exact reason why i was first thinking of an "overclocking" option.
Most intensive 3D graphic applications are limiting themselves to 30 FPS for the same reason.
I think that we must be pragmatic and do our best to preserve the user interaction, your thought ?
Added:
I just read your previous post right now
wglSwapInterval(2) call and you'll get your stable 30 frames per second legally
Yes, perhaps wglSwapInterval(2) is the solution, i never used it so far.
Looking on how to use it.
-
I rather used the 360o button on the LS panel for this demo implementation. Feel free to accommodate it to the Y rotation mode checkbox. I don't think we really need it to duplicate the button anyway.
30FPS is the default, 60FPS is "turbo". Have Fraps running and try to drag-and-rotate the model at the default setting. You'll see the FPS rate never exceeding 30. Switch on the "turbo" mode by clicking the 360o button on the LS panel and watch the maximum rate climb up to 60FPS. Same applies to the Y rotation mode.
Search for MLL 02-18-2018: to see my mods.
The CPU/GPU load/system responsiveness is still dependent on: (in the order of importance)
-- poly count
-- default/maximized/full screen window size
-- visible distance to model
-- "illuminate both sides" setting
-- PPL or FFP
-- number of material textures (and consequently, number of texture lookups in the shaders)
-- backface culling
-- etc.
______________________________________________
P.S. Can we have an event fired when the nVidia/ATi icon is clicked in the main window caption? I'd like to see it pop up a small message box (similar to About...) to display some basic info on the current OpenGL video driver.
-
:o :o :o :o
OMFG!!!
It isn't textures -- same thing seen untextured too!
I swear I didn't touch the shaders; that must be something related to either VBO's or IBO... I'll look into the matter tonight. Any glitches seen in the other models?
[UPD] It seems to be related to fast trig func approximations and needs further investigation...
-
No, the approximations aren't the immediate cause. They do have a very slight effect in the overall look of normals+tangents because they are used in both calculations and thus add up to each other, but not to such an extent as to make vast areas of adjacent polies unrenderable like this. My investigation is still in progress...
-
Can we have an event fired when the nVidia/ATi icon is clicked in the main window caption? I'd like to see it pop up a small message box (similar to About...) to display some basic info on the current OpenGL video driver.
Here is the code to be completed
LRESULT CALLBACK WndProc(IN HWND hWnd, IN UINT uMsg, IN WPARAM wParam, IN LPARAM lParam) {
long nW = 0, nH = 0, K, nMeshCount = 0, nValue = 0, nStatus = 0;
HWND hCtrl = 0;
MINMAXINFO* pMM;
NMLISTVIEW* ptNMLV;
NMHDR* ptNMHDR;
WCHAR zTxt[MAX_PATH] = { 0 };
POINT p = { 0 };
RECT rc = { 0 };
static long nSmoothMode;
switch (uMsg) {
case WM_NCLBUTTONDOWN:
GetWindowRect(GetDlgItem(hWnd, IDC_GRAPHIC_CARD), &rc);
p.x = LOINT(lParam); p.y = HIINT(lParam);
if (PtInRect(&rc, p)) {
wcscopy(zTxt, L"\nPut your message there");
skDialogInfo (L"Graphic card", zTxt, L"");
}
break;
My investigation is still in progress...
I am crossing my fingers, for a solution that would preserve the use of VBO ???
[UPD]
It seems that the new Q_fabs used to compare to epsilon, has an impact, restoring the original fabs code works better, however not perfect.
-
Here is the code to be completed
Thank you! I will use it when I'm through with the Ramjet glitch.
... preserve the use of VBO
There is no stopping VBO usage nor is there any alternative, just as there is no alternative to perpetual code optimization to make the render procs run faster and faster. Everybody else can do it, which means we will be doing the same eventually. And nobody is immune to mistakes. Professionalism means not being able to write bugless code, which is unrealistic, but rather being able to isolate the bugs promptly and eliminate them efficiently.
Re: UPD
Yes, I noticed it too. But I have a strong feeling that, once the true cause of the bug is eliminated, the approximations will resume their respective places in the code.
-
IT WAS ALL BECAUSE OF MY OWN INATTENTIVENESS AND NOCTURNAL LIFESTYLE! >:( :-[
I was typing the new VBO glXxxPointer() calls by hand rather than copy-pasting them from the old VBA version and I overlooked that, though we're passing tangents to the shader as simple tex coords, we are storing them as float[4], rather than usual float[2], arrays.
To cut it short, leave all of the approximations alone exactly as they are in my code. They've got nothing to do with the glitch. Now goto Mobj_DrawUsingProgrammablePipeline() in mobj.h, scroll it down ca. 2/3 of its length, and fix the following:
........
if (gnm_hasTangents) {
glClientActiveTexture(GL_TEXTURE1);
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
//glTexCoordPointer(4, GL_FLOAT, nVertexSize, Mobj_getVertexBufferTangent());
glTexCoordPointer(4, GL_FLOAT, sizeof(MobjVertexT), (GLvoid*)32); // MLL 02-08-2018: 32 byte offset to 1st tangent
}
........
That'll do the trick.
-
Mike
Are you sure that you didn't change anything else, because that fix doesn't work by me with RAMJET :-[
[UPD]
That seems to work by me, only if i restore the original epsilon value, aka:
if (Q_fabs(rExtent) > 0.000001f) rScalingFactor = rScaleTo / rExtent; // MLL 02-09-2018: compare to epsilon!
Added
While RAMJET is working fine with epsilon 0.000001f, i still have problem with another new model. It always look good in FFP mode, and has several black sections in PPL.
More
Looks like using bump mapping could be the problem.
-
Here is a single mesh to check with.
REM OUT map_bump from the mtl file, and switch to PPL mode, then it works correctly.
Conclusion, the problem occures only when bump mapping is used.
Mobj_generateTangents() ?
-
Yes. Tangent generation occurs only for the materials that have normal maps and thus use the gnm_NormalMappingShader program in Mobj_DrawUsingProgrammablePipeline(). Materials without normal maps use the gnm_BlinnPhongShader program that neither expects nor needs tangents when in the Mobj_DrawUsingProgrammablePipeline() mode. Finally, the concept of tangent space doesn't even exist in the context of immediate mode FFP.
-
OK Patrice,
So here come my tangent misalignment fixes.
All the approximations and epsilons are in their proper places, and a couple more added. A few superfluous statements have also been fixed. Everything seems to be running faultlessly for me now.
Your GPU button event code will go into v3.0. Please don't delete that message from the board yet; I'll do it myself when the time comes.
Let my comments stay in the sources for a while longer. We may clean them when the code proves to be safe and stable.
Enjoy! :)
-
Thank you very much my friend !
Everything looks perfect with this fix.
Now i can complete my work on the "millenium falcon" ;)
-
However could you review this post (feel free to edit anything you want).
http://www.objreader.com/index.php?topic=2.msg2627#msg2627
[UPD]
Patrice,
I made some slight grammar corrections in a few sentences but as far as the technical content is concerned, there's nothing much to add or alter.
-
The background texture issue is FIXED.
Patrice, your ZI_DrawGLText() was unbearably heavy for my CPUs. It kept eating up to 30% of their usages even when FPS was on but there was nothing loaded in the viewer.
Now the usage is no more than 1% extra as compared to FPS off. Some extra GPU is no wonder because when FPS is on, the viewer enters a continuous render mode where it always has something sizable to draw -- the wallpaper quad, as a minimum -- and that's what accounts for the GPU usage. So, I removed the "extra CPU/GPU" notification from the menu.
Please put the new PNG in \Reader and recompile with the new Main.cpp and mobj.h. Now v2.5 Stable may go public. (hopefully ;) )
P.S. The trailing argument in your Mobj_CreateGLTextureFromFileEX() is not a yes/no Boolean as the gP description erroneously states, but rather something that can have at least 5 different values in the 0 to 4 range. Can we have these values gathered into an enum with meaningful names to prompt the developer with what to expect from the function?
-
Mike
My ZI-DrawGLText must deal with any kind of string and color, moreover all my applications are now using native UNICODE strings that must be first converted to CHAR to deal with OpenGL.
MLL: removed from prying eyes of nosey peepers. ;)
However for the specific case of FRAPS, of course we can make it very simple.
I even have a function to display TTF private fonts that is even more complex, however very handy (Chart3D).
BTW: We could rem out all the code related to the creation of the "TREBUCHET MS" font, if we don't need it anymore, however i must make sure first that we won't use it in the future...
-
Patrice,
Whatever and wherever, but not in the ObjReader render proc and not while I'm hanging around. ;)
No, you are not going to split one and the same pure green color into components 60 times per second in each ObjReader frame. And you are not going to translate WCHAR's to char's in your zMsg that you could have declared and used as a char[] buffer from the very beginning, over and over again 60 times per second in each ObjReader frame.
-
I did it myself, because i want the digits to respect the theming of the skin.
However you will still be able to use the FRAPS one for your own purpose if you prefer. 8)
the png size would be exactly the same with a 32x32 digit cell.
-
Patrice,
My cells aren't 32x32, they're 16x26 but I need an exact POT grid size to avoid OpenGL+GDImage+Glu32+god knows what proxy else to resample my texture to keep it crisp and clear of multisampling. Hence extra translucent margins. (BTW what about my request for the enum?)
P.S. Your code is all right with my boxes; no CPU load detected.
-
GDImage is able to handle any kind of texture without resampling.
I shall tell you what enum to use, but let me have a look at my code first ;)
Personnaly i find ridiculous to maintain two distinct version of the same project, thus i shall use your FRAPS even if doesn't match my artistic taste :-X
-
1 = Create square texture
2 = Stretch to memory bitmap
3 = Accept texture of any size
4 = MipMapping
With ObjReader we can safely ignore 1, 2, and use either 3 or 4.
But for your FRAPS, 3 is the good one to use (what you have done already).
-
Oh no no no Patrice!!!
You are the project lead and copyright owner, and your superior artistic taste is above and beyond any questioning!
It's just that I'm having the privilege to be able to recompile the binaries to my needs at my own option. They aren't going anywhere beyond my own monitors. And it is not difficult for me to revert my personalizations back to the official version before sending you my mods. :)
So v2.5 goes public with your gasoline station digits. :-X
-
My dear friend,
You are being very kind to praise my humble odd job so high. I have always said it is my pleasure to assist you in this project.
My sincere congratulations on the occasion of your birthday! In fact we have already neared the age when every birthday is actually a jubilee.
(https://emojipedia-us.s3.amazonaws.com/thumbs/120/emoji-one/104/thumbs-up-sign_1f44d.png)
-
It renders autorotated Millenium_Falcon absolutely beautifully @ 60FPS and a quarter of dual-core CPU load even on my AMD box.
Congratulations, partner! :D
-
Mike
Thank you for the confirmation.
Here is the patch (binary + source) to be compatible with VS2010, and solve the mouse scrolling problem ::)
...
-
Thanks Patrice,
Now it works fine for me. :)
Aha! Now you see that to rely on a C compiler to do something for you on default isn't very wise! Initialize your vars explicitly and you won't fall into that trap again! 8)
-
Aha! Now you see that to rely on a C compiler to do something for you on default isn't very wise! Initialize your vars explicitly and you won't fall into that trap again!
Indeed the variables were assigned directly into the structure, but that is a NoNo with VS2010, thus i have to moved it in the LS panel control code creation, also had to change a couple of ansi deprecated string API to there _s (secured) version. :)
-
It's quite a surprise for me that MS VC (2010) wouldn't throw an error and allowed you to compile the code at all! :o