ObjReader Community
WIP => WIP => Topic started by: Michael Lobko-Lobanovsky on March 31, 2019, 03:26:09 am
-
Well, this is ObjReader's first ever render through a 16x MSAA FBO with a simple vignette PP shader. :D
(... at a full FPS rate that's twice lower than it would be without FBO and PP. :( But as a bonus, we can now select the MSAA level in real time. 8) )
-
Thank you my friend for your hard work!
A little WIKI definition about the meaning of MSAA, for the dummies like myself.
Multisampling, also known as multisample antialiasing (MSAA),
is one method for achieving full-screen antialiasing (FSAA). With multisampling, each pixel at the edge of a polygon is sampled multiple times. For each sample-pass, a slight offset is applied to all screen coordinates. This offset is smaller than the actual size of the pixels. By averaging all these samples, the result is a smoother transition of the colors at the edges. Unlike supersampling (SSAA) which can result in the same pixel being shaded multiple times per pixel, multisampling runs the fragment program just once per pixel rasterized. However with MSAA multiple depth/stencil comparisons are performed per sample, one for each of the subsamples, which gives you sub-pixel spatial precision on your geometry and nice, smoothed edges on your polygons.
(http://www.zapsolution.com/pictures/Antialias.jpg)
History
Before GL_ARB_multisample extension, the edges of lines, polygons, and points could be selectively antialiased using using glEnable(GL_LINE_SMOOTH), glEnable(GL_POLYGON_SMOOTH), glEnable(GL_POINT_SMOOTH) respectively, combined with a blending function, such as glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA). Such features were typically not implemented in hardware in early consumer graphics cards at the time, and were done in software resulting in poor performance. More expensive "workstation" graphics cards from HP, Sun, and SGI at the time did implement these features in hardware. Modern programs should not make use of these features.
Rendering with Multisampling
There are two pieces to rendering with multisampling:
1.Allocating a multisample render target (window or FBO), and
2.Enabling multisample rasterization (i.e. glEnable( GL_MULTISAMPLE ))
While the second step is standardized across all render target types and platforms, the first is only standardized for FBOs (as it is totally internal to GL). When rendering to a window, the allocation method depends on the platform-specific GL integration layer in-use (e.g. WGL, GLX, AGL, etc.). GLUT provides a wrapper around some of these so you don't have to care.
More insight there:
https://www.khronos.org/opengl/wiki/Multisampling
-
That's perfectly correct, my friend! :)
Before, we had to select a proper MSAA-capable pixel format in a two-stage Mobj_choosePixelFormat() procedure at app start. Now, the screen rendering context may be left simple (without the MSAA selection loop) like in any simplest OpenGL example app.
The MSAA level (typically 16x) is selected and applied directly to the MSAA FBO when the FBOs are created in OR (actually, two of them: one MSAA'd for the actual frame renders, and one simple for screen quad texture creation). As FBOs must follow the gP.hGL size exactly but are non-resizable by design, they are to be re-created from scratch each time gP.hMain is resized for whatever reason. This is where a user-selectable MSAA level may be applied. 8)
Alternatively to MSAA, we may use an FXAA shader like here (http://www.objreader.com/index.php?topic=78.msg371#msg371), which would be significantly more light-weight (hence faster) than full-scale MSAA.
Finally, nVidia (not ATi!) users may also optionally enjoy CSAA (https://www.nvidia.com/object/coverage-sampled-aa.html) (Coverage Sampling Anti Aliasing), which is claimed to be as fast as 4x-only MSAA while yielding quality not worse than 16x MSAA.
______________________________________________
Here is a sample build of FBO OR for you to play with. Please report if it works OK under your W10.
Note: wireframe and point cloud modes are currently incompatible with the new code and produce a black screen!
-
Please report if it works OK under your W10.
No, it doesn't, OR is not visible, nothing happen when trying to start the application.
-
Try renaming it to ObjReader64.exe, please.
-
Sorry, but renaming to ObjReader64.exe, doesn't work either.
-
I'll investigate the situation and inform you later.
-
:D :D :D :D
8)
-
Bravo!
-
Thanks! :D
This is to inform you why I'm not rushing to supply you with the new toy that's now working flawlessly for both nVidia and ATi as well as W7 and W10.
The use of FBO doesn't affect our gl_DrawScene() and associated procs in any way as the code is 100% reusable. So, we're able to switch between direct and FBO rendering on the fly and thus basically turn post-processing off or on in real time. This requires appropriate menu switches and rock-solid initialization routines. That's what I'm working on now.
Further, we can also switch between direct and FBO MSAA in real time too. However, FBO MSAA requires a non-anti-aliased pixel format in gP.hGL while in the direct mode, the format should be 16x MSAA capable. So, I have to rework the pixel formatting routines accordingly.
Finally, such 3D editors like 3ds Max and Blender and some others can outline a selected mesh. Moreover, apart from the regular selection and mesh info tips, 3ds Max can outline dynamically the mesh that's currently under the cursor. And it does it depth independently so that the entire mesh is outlined not obscured by the other ones. (see the attached screenshots)
I am able to, and will, do the same in OR, and with a selectable color and thickness of the outline. It's gonna work in both direct and FBO modes of operation. 8)
-
Thank you for your efforts!
-
Well, how's your Royal Procrastinated Majesty feeling your precious self? :D
I remember I used to play truant from ObjReader for months. Sure you ain't gonna keep me alone that long, are you? :D
OK, here's the toy. It isn't yet complete or particularly stable (there may be some glitches with resizing and un-vsync'ed full-speed rendering) but it generally works for me on all my boxes, and promises to work still better in the future.
What it can do- It can run in direct or FBO modes (Inspect->Use framebuffers toggle).
- It can use or not use a vignette PP shader (Renderer->Vignette toggle).
What it cannot do- It can't currently adjust its gP.hGL and FBO MSAA in real time yet (hardcoded at 16:8 samples, respectively, to satisfy both my nVidia and ATi video cards and direct or FBO modes of operation). So, its FPS rate is somewhat slower than it should be with just 1x MSAA in the viewport canvas when FBO is on.
- It doesn't currently support wireframe or point cloud modes (the viewport goes black).
It's been compiled to my options, not yours, so I'm also including the 69.png FPS texture as I'm not sure if you still have one to be able to inspect the relative FPS rates. Please tell me if it works for you this time.
-
Thank you!
It seems to work fine by me on W10.
It's been compiled to my options, not yours, so I'm also including the 69.png FPS texture as I'm not sure if you still have one to be able to inspect the relative FPS rates.
Since at least the two last versions, i have been using the same FRAPS font (however smaller font size) to please you, as you can see on the attached screen shot.
-
It seems to work fine by me on W10.
Wonderful! :)
... to please you, as you can see on the attached screen shot.
:D
Your monkey looks pretty BTW. (though mine is only 415KB large and loads in some 0.35 seconds. ;))
-
Another simple single-pass PP shader -- "bloom".
No, this isn't "glow". Glow cannot be done in one pass because it involves texture re-scaling and gaussian blurs. Strictly speaking, bloom shouldn't be done in one pass either but it can still be (roughly) emulated in 2D screen space.
Bloom attempts to emphasize brightness of spot highlights in the screen quad. Due to the extreme simplicity of this shader it does currently generate certain sampling artifacts but they can be minimized by adding more elaborate screen texture sampling scenarios.
Also, this shader uses some rough gamma correction and is thus handy for making PBR-like albedo look more "juicy".
-
Thanks for sharing.
That could be handy to create cartoon like effects, even if my own preference goes for everything that could be closer to photographic's.
-
Cartoon?! Not one of those screenshots looks anywhere near toonish!
Calling bloom toonish sounds humiliating... :(
(FYI: Do you know how large annual revenue is in the video game industry worldwide? 138 billion US dollars! Video gaming has always been, and still is, the major driving force behind the world's steady progress in computer development and production.)
-
Calling bloom toonish sounds humiliating...
Nothing humiliating there, see the attachments it makes me think about.
Search google for OLYMPUS MONS, BD, anomalie
and CALL of DUTY
-
My friend,
Re. Falcon above, add here a little fog, depth of field and bokeh, and you'll get the CoD look and feel as seen in your bottom screenie.
The Simpsons, Sponge Bob and Super Mario are toonish but CoD bloom is virtual reality.
Imagine what a sunny day would look like somewhere in the bright hot African savanna or stone-cold snowy Canadian or Russian tundra, or at least how les Champs-Élysées (https://www.videoblocks.com/video/france-paris-arch-de-triomphe-and-champs-elysees-traffic-at-night-time-lapse-jignslg) would look deep in the rainy night. Then you'll get the idea of how photorealistic bloom is. ;)
-
Hey,
Does this bloom look better (more veritable) to you? It doesn't have that "lollypop" color tint any more that you seem to dislike so much...
It has no dedicated shader controls window yet and currently depends only on the current scene brightness setting. (in the snapshots below, 30, 50, and 75 per cent, respectively)
__________________________________________________________
The difference between bloom and glow is that bloom is an incident light effect that emphasizes (over-brightens) the diffuse and specular highlights on the model surface and is thus restricted to that surface. Conversely, glow is a volumetric emissive light effect whereby it is projected out of the model, such as e.g. a glowing neon sign or a rocket jet flame, and into the surrounding air space.
-
Does this bloom look better (more veritable) to you?
For me it is hard to say from static images.
So far it looks very close to what i could get already when playing with the "straylight" brightness slider and multilight settings.
(see the attached screen shot, that is preserving more the face details)
However you are doing direct experimentation, thus you have a better clue than myself.
Perhaps could be very handy to use with some specific meshes (for example to enhance glowing light) rather than the whole model?
-
Perhaps could be very handy to use with some specific meshes (for example to enhance glowing light) rather than the whole model?
Unfortunately, no, not in its current state. This is a "fake" bloom applied to the entire gP.hGL viewport including the background in the second render pass (stage 4 below) when the textured screen quad is rendered from video memory into the viewport with a distinct dedicated shader. In other words, the effect takes place in the entire 2D screen space after the scene has already been rendered. The vignette effect also has a similar dedicated shader of its own. The bloom shader makes all of the quad areas lit brighter than a given threshold appear yet brighter and super-sampled around the current fragment/texel (= screen pixel because the screen quad matches precisely the viewport's current size) to "leak" the bloom areas into their surroundings.
The current FBO rendering scenario consists of the following stages:
1. Render scene into MSAA FBO -> 2. Blit MSAA FBO into non-AA FBO's texture -> 3. Bind texture to quad -> 4. Render quad on screen
A genuine bloom effect would require that stage 4 be split into additional sub-stages with yet more render targets/textures added for scene image minification, blurring, magnification, and additive blending with the original screen quad texture. This would complicate greatly the current OR dev stage. That's why I'm trying to avoid shader management over-complication till better times and tend to make a shift with as simple shaders as possible.
[P.S.] And no, you can't emulate bloom entirely with the straylight fader and/or light/material controls alone because bloom has a certain threshold below which it doesn't occur no matter what the current lighting environment is. That is, bloom is selective. Conversely, the brightness and lighting controls have a linear effect, i.e. they brighten and dim all the areas in all the materials simultaneously and proportionately regardless of whether they are bright or dark. And bloom intensity above the threshold level is exponential rather than linear.
-
OK, thank you for the detailed explainations!
-
Well, if now you say again this lightweight and simple depth-of-focus + bokeh PP shader is of little or no aesthetic value either, I'm gonna get real irritated... ;)
OK it is not linear but circular; there's only a relatively small circular area at the screen center that's fully in focus. And the bokeh spots aren't filled in but rather look like circles. But it's also only a simple 2D screen space emulation of full blown and rather complicated 3D scene depth-based DOF and bokeh post-processor.
It's also sort of another placeholder till better times when I've got nothing else to do but fiddle with the OR shaders. ;D
-
I like this very very much!!!
-
Dvergr on its quest for the unknown...
(Configurable radial blur post-processing)
8)
-
That is another great one effect!
-
Tell you a secret, we're very very close to having true dynamic soft shadows in OR... :)
-
My friend,
As I can vaguely recollect, some time ago when we used to discuss PBR materials, you said something about developing a model that's actually a flat array of balls like they usually use to display a set of material samples and/or their transformations. Did you actually implement such a model? I'd like to have one to experiment with real-time adjustments of fake Depth-of-Field PP shader like in the snapshot below:
-
Radial blur with fake chromatic aberration
I like Nefertiti and Time Machine (in action...). :)
-
Is that what you want?
-
!!! PERFECT !!!
Thanks a bunch! :)
-
Good morning and have a nice day, my friend! :D
-
I am sorry, but honestly that effect is not one i would like to use, except perhaps to create an image reflection on a sphere. :-\
-
Patrice,
We will discuss which post-processors exactly you'd like to see in the public build, and those that won't make it in there will be #ifdef MLL_DEV'ed out in our shaders.h sources.
-
I'm currently experimenting with real 3D DOF+bokeh post processing. Apart from the scene quad color texture, it requires concurrent creation of a scene depth texture and, consequently, one more MSAA renderbuffer blit into a non-AA FBO.
I can't yet make out correct positioning of my focal point in 3D space (see the picture below). But what I can already tell you is that the shader is going to be heavy despite renderbuffer blitting being blazing superfast as compared to ordinary slow glReadPixels(). The FPS rate drops 4 times lower than when rendered directly into an AA-unaware FBO.
This makes real time animation of complex models through genuine 3D, rather than fake 2D, post-processors highly problematic unless we abandon MSAA in favor of non-AA FBOs with much faster programmatic CSAA and/or FXAA shader solutions used in all modern professional 3D engines for similar reasons. ???
-
I'm stuck with depth-based PP. MSAA and related necessity to blit its render buffers into a non-AA FBO prior to being able to utilize the resultant scene textures are a severe bottleneck that puts a heavy load on the rendering pipe line and causes a dramatic drop in the OR FPS rate.
I think I should drop this activity for the time being and rather see what else I can do with simpler 2D effects -- including FXAA and CSAA shaders that may prove to be the key to much faster anti-aliasing without loss of quality in the viewport quad image.
-
My recent depth-based FBO experimentation has seriously broken my successful pipeline solution that I built when debugging FBO for W10/ATi compatibility. I'm not yet able to revert it to what it used to be; I'm lacking the necessary intermediate saves I should have done in the experimentation process. :-[
I'm sad to admit it but it looks like the older I become, the more monkey work I'm forced to do... :'(
-
the older I become, the more monkey work I'm forced to do
That is the same for the old lemur here ;)
However keeping our neurones at work is a good medecine to delay the deadline...
-
I'll be damned but I found the bug that was keeping me stuck for so long!
It was a seemingly very logical but actually very unfortunate glDisable(GL_TEXTURE_2D) in one of the draw lists that carried its bad side effect over into the next render frame!!! >:(
Now I can finally resume my FBO WIP... 8)
-
I am glad you found it, that is a very good news!
-
[UPD]
1. FBO (default) doesn't render wireframe or point cloud. But since we can disable it (for backward compatibility) and still render them directly into gP.hGL, I'm just disabling Wireframe/Point cloud while FBO is on.
2. I've restored wallpaper renders in Wireframe/Point cloud modes "to please you"(c). ;)
-
Another idea: what about moving both Wireframe and Point cloud over to the Renderer menu?
FYI I'm currently implementing PP shading options (vignette, bokeh, etc.) at the bottom of Renderer menu under a divider beneath the "fancy modes" group. Wireframe and Point cloud could go there too under their own divider...
-
Patrice,
1. GDImage.cpp, ZI_MakeMultipleTexture(...), line 8842:
// MLL: _MIPMAP_LINEAR cannot be used for _MAG_FILTER as per OpenGL Specs !!!
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR GL_LINEAR);
OR's Mobj_makeMultipleTextures(...) does not have this bug. 8)
2. I've suddenly realized that neither GDImage nor ObjReader use anisotropic texture correction. (see the floor below for what its effect looks like)
My suggestion is to use aniso = 8 because:- It is almost as good as the best setting but according to comments on the net, 16 adds transparently yet some extra MSAA to MSAA's current best setting (defaults to 16 in ObjReader) and is therefore extremely heavy on the GPU.
- Apart from MSAA, we are also going to optionally use CSAA (nVidia only) and FXAA selectable from the menu. We do not want two different AA algos to be intermixed concurrently in one render. (aniso = 8 works in both CSAA and FXAA as is)
Do you agree with me here?
-
I shall fix GDImage to use GL_LINEAR, thanks!
My suggestion is to use aniso = 8 because:
To say the truth i couldn't see any difference, just use the one that looks better to you.
-
:o
!!! WATCH THE FLOOR SEAMS AS THEY GO HEAVILY BLURRED IN THE DISTANCE IF THE FLOOR TEXTURE ANISOTROPY IS NOT CORRECTED !!!
(Please also answer my other suggestions in earlier messages. Hopefully you haven't yet lost interest in ObjReader. ;))
-
1. GDImage.cpp, ZI_MakeMultipleTexture(...), line 8842:
// MLL: _MIPMAP_LINEAR cannot be used for _MAG_FILTER as per OpenGL Specs !!!
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR GL_LINEAR);
Obviously we do not have the same source :o
ZI_MakeMultipleTexture is at line 9467 by me, and the code is rather different than the one used in Mobj_makeMultipleTextures :o
Here is the code i have:
void ZI_MakeMultipleTexture (IN ZGLTEXTUREX* mt, IN long mtCount) { // dllexport
if (mtCount> 0) {
long K, OkDelete = 0;
long* Texture = new long[mtCount];
memset(Texture, 0, sizeof(long) * mtCount);
for (K = 0; K < mtCount; K++) {
Texture[K] = mt[K].Texture; if (Texture[K]) { OkDelete = -1; }
}
if (OkDelete) { glDeleteTextures(mtCount, (GLuint*) Texture[0]); }
glGenTextures(mtCount, (GLuint*) &Texture[0]);
long nRet = glGetError();
if (nRet == 0) {
for (K = 0; K < mtCount; K++) {
BYTE* lpArray = NULL;
long xSize = 0, ySize = 0;
gl_TexAlpha(0, 1); // 05-10-2015 to detect if we are using an alpha channel
if (ZI_CreateGLTextureFromFileEX(mt[K].FullName, xSize, ySize, lpArray, mt[K].Square)) {
mt[K].Texture = Texture[K];
mt[K].alpha = gl_TexAlpha(0, 0); // 05-10-2015 to detect if we are using an alpha channel
GL_BindTexture(GL_TEXTURE_2D, Texture[K]); nRet = glGetError();
if (nRet == 0) {
if (mt[K].Square == 4) { // MipMapping in ZI_CreateGLTextureFromFileEX
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
gluBuild2DMipmaps(GL_TEXTURE_2D, 4, xSize, ySize, GL_RGBA, GL_UNSIGNED_BYTE, lpArray);
} else {
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, 4, xSize, ySize, 0, GL_RGBA, GL_UNSIGNED_BYTE, lpArray);
}
nRet = glGetError();
}
free (lpArray); //zizi
}
}
}
delete [] Texture;
}
}
-
This is because I have very old pandora as far as GDImage is concerned. ;D
See below:
void ZI_MakeMultipleTexture (IN ZGLTEXTUREX* mt, IN long mtCount) { // dllexport
if (mtCount> 0) {
long K, OkDelete = 0;
long* Texture = new long[mtCount];
memset(Texture, 0, sizeof(long) * mtCount);
for (K = 0; K < mtCount; K++) {
Texture[K] = mt[K].Texture; if (Texture[K]) { OkDelete = -1; }
}
if (OkDelete) { glDeleteTextures(mtCount, (GLuint*) Texture[0]); }
glGenTextures(mtCount, (GLuint*) &Texture[0]);
long nRet = glGetError();
if (nRet == 0) {
for (K = 0; K < mtCount; K++) {
BYTE* lpArray = NULL;
long xSize = 0, ySize = 0;
gl_TexAlpha(0, 1); // 05-10-2015 to detect if we are using an alpha channel
if (ZI_CreateGLTextureFromFileEX(mt[K].FullName, xSize, ySize, lpArray, mt[K].Square)) {
mt[K].Texture = Texture[K];
mt[K].alpha = gl_TexAlpha(0, 0); // 05-10-2015 to detect if we are using an alpha channel
GL_BindTexture(GL_TEXTURE_2D, Texture[K]); nRet = glGetError();
if (nRet == 0) {
if (mt[K].Square == 4) { // MipMapping in ZI_CreateGLTextureFromFileEX
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR GL_LINEAR); // MLL: ZUZU :D
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_REPEAT);
gluBuild2DMipmaps(GL_TEXTURE_2D, 4, xSize, ySize, GL_RGBA, GL_UNSIGNED_BYTE, lpArray);
} else {
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexImage2D(GL_TEXTURE_2D, 0, 4, xSize, ySize, 0, GL_RGBA, GL_UNSIGNED_BYTE, lpArray);
}
nRet = glGetError();
}
free (lpArray); //zizi
}
}
}
delete [] Texture;
}
}
-
!!! WATCH THE FLOOR SEAMS AS THEY GO HEAVILY BLURRED IN THE DISTANCE IF THE FLOOR TEXTURE ANISOTROPY IS NOT CORRECTED !!!
YES, using my computer glasses i see it now (i was wearing my distant glasses)
And 16 looks the better to me, but i can live with 8 ;)
-
This is because I have very old pandora as far as GDImage is concerned.
No, i sent you the latest version two weeks ago :-\
-
No, i sent you the latest version two weeks ago :-\
That's correct; my bad.
I opened up an old CPP dated 12/14/2018...
It's line 9489 in CPP dated 4/19/2019 with TGA and DDS code.
(I'm keeping a history of pandoras but opened the oldest copy for no apparent reason... :-[)
-
... i can live with 8 ;)
So be it! :D
(Still, what about moving Wireframe and Point cloud menu elements over to the Renderer menu?)
-
Yes, that would be easier to move them into the "Render" menu, rather than having first to select "View" then "Render mode control"
-
Thanks for responding! I'll include the new layout in the nearest coming test build for you to evaluate.
... the code is rather different than the one used in Mobj_makeMultipleTextures :o
The GDImage original code was too basic and simple to be used in OR as-is. We had to follow a much more elaborate scheme to decide on the fly if the current texture needed and/or allowed clamping and/or mipmapping at load time. So we extended the ZI_MakeMultipleTexture code into a dedicated Mobj_makeMultipleTextures function leaving out the GDImage original altogether.
That also enabled me to maintain the code of this very sensitive stage in OR's model loading process independently, without having to ask you to reveal much of GDImage internals every time we had an issue to resolve.
-
OK, I just want you to see what I'm working on.
These are 5 fully debugged 1-pass production quality 2D PP shaders:- hue/saturation (in one shader)
- brightness/contrast (ditto)
- sepia
- vibrance (that's sort of selective saturation that affects only insufficiently saturated colors)
- vignette.
All are fully and smoothly controllable. They are also very lightweight; the heaviest one, vignette, incurs blur but still costs not more than about 2% FPS on a 32x MSAA/8x aniso canvas.
There are more to come. But those 5 are already sufficient to start merging them into a conditionally compilable composite PP shader that will allow us to use any number of such PP effects in any combination with only a minimum loss in the FPS rate.
-
OK, I just want you to see what I'm working on.
Thanks!
I shall have to see them in context, to see how they can permanently enhance the rendering of the existing models.
On my side, i shall try to work back on the UV's undo/redo problem. ::)
-
...i shall try to work back on the UV's undo/redo problem. ::)
What about developing a WYSIWYG material editor for a change? :) You know, all those material balls, matcolor and opacity sliders and stuff, rather than a primitive text editor for .MAT contents... 8)
Though even the text editor with MAT syntax highlighting and real time update of the already loaded model (only the MAT file reloadable to actualize the mods) would be a great plus...
Re. PP, I'll send you a working build with separate shaders later today. I have urgent real life matters to attend to first. :)
-
What about developing a WYSIWYG material editor for a change? :) You know, all those material balls, matcolor and opacity sliders and stuff, rather than a primitive text editor for .MAT contents... 8)
Though even the text editor with MAT syntax highlighting and real time update of the already loaded model (only the MAT file reloadable to actualize the mods) would be a great plus...
To say the truth, about the text editor, the only thing really useful to me, is the hability to create a transparent UV's map, that i could use as a guidance for my PSD texture work.
The main problem with Tor, is not the undo/redo, but saving the changes to the obj file :-\
Something else …
I would like to see in OR the use of animated "shadertoy" backgrounds, to bring the models to life.
-
To say the truth, about the text editor, the only thing really useful to me, is the hability to create a transparent UV's map, that i could use as a guidance for my PSD texture work.
I knew you'd be clutching to your existing and familiar toolchain as tight as you only could. But do you realize how much of your precious lifetime you spent waiting for the model to reload when working with e.g. Blenderman's materials? Why you wouldn't want to have all the material editing facilities directly in OR is a mystery to me... ::)
The main problem with Tor, is not the undo/redo, but saving the changes to the obj file :-\
The main problems with Tor are, alas, its low resolution, general blurriness, and shallow zoom. :-\
I would like to see in OR the use of animated "shadertoy" backgrounds, to bring the models to life.
That's on my to-do list.
-
The main problems with Tor are, alas, its low resolution, general blurriness, and shallow zoom.
How would remove bluriness when zooming the existing texture background, this is a mistery to me, because you have either to remove or add extra pixels, and the only way to get a better quality is to use bicubic interpolation but this algo is too slow to edit things in real time.
Also remember that we are working in 32-bit composited mode and conventional memory.
The only solution would be to work with a back buffer, and bypass the GDImage zoom control, to manipulate just the part matching the view port.
The current bluriness is the exact same thing you got in Photoshop when working with the transparent UVmap and multiple layers.
For me, i keep saying that the main issue is to save the changes into the OBJ file.
-
My friend,
If you feel uneasy or confused about working on Tor-based UV editing, then let's put that idea aside for later. Probably the proper time for the UV editor hasn't come yet. The space to the right of splitter may in the meantime be used for other useful purposes. Or the splitter may simply be locked to the right side panel for the time being keeping other associated code untouched for later use when needed.
-
Patrice,
I'm currently preparing my sources for merger based on MSAA FBO post-processing and initial animated background support.
My proposition is to exclude Tor code from the project. Frankly, I don't believe it's going to meet the expectations. Granted, it's very spectacular like everything you do. But it was originally designed for another project, and modding it to ObjReader's needs takes far too much effort that can better be spent more efficiently.
Some day I'll design a lightweight UV editor based on my FBSL code. But not now because we still have more immediate needs that can be implemented in the MAT files without touching the OBJ structure proper.
I'm hoping you'll agree to my proposition. Will you?
-
For now, i am using it just to create and save the UV's map into a transparent png.
-
Whatever!
But do you agree in principle to suspend Tor/UV editor development at this stage? Won't it hurt you too much?
-
But do you agree in principle to suspend Tor/UV editor development at this stage? Won't it hurt you too much?
No problem, Tor is very easy to disable, and i have already all what i need in C4D that is the tool i use to create/edit all my models, including UV's map. ;)
-
I'm definitely getting old and nearing marasmus.
I've just discovered that if I press Alt when in the mesh info tip mode, all the meshes that are not under the cursor get hidden and I can inspect the selected mesh unobscured by the others for as long as I keep on holding the Alt button down. :o
On scrutinizing the sources, I was surprised to find out it was me who had implemented that brilliant feature. 8)
Amazing! ;D
-
Yep, very handy!
-
Yet it isn't reflected in the help. It was probably added after ObjReader v2.75 had been released but I'm not sure...
-
OK Patrice,
I think have straightened out my MSAA FBO WIP sources for the merger.
Do you think I absolutely must add animated backgrounds before we merge the sources or they can wait for some more experimentation? There are bound to be some more issues to work upon like e.g. the need to create background snapshots (most likely, minified) to be used as reflection maps where necessary. I don't think we should create them each frame to look animated too because it can overload our pipelines...
If animated backgrounds can wait then I'm more or less ready to send you the sources. Just let me know.
-
Patrice, please wake up and respond to my previous message. ;)
-
If animated backgrounds can wait then I'm more or less ready to send you the sources. Just let me know.
Yes, animated backgrounds can wait… 8)
-
Okay here we go:
-2. All significant mods bear a MLL 03-30-2019: tag.
-1. Currently, culling (see item 3 below) does not work for glassy meshes until we have a dedicated glass shader and proper dynamic back-to-front alpha sorting for all transparent meshes depending on current model orientation.
0. The sources have no trace of Tor.
1. OR uses a 32x MSAA FBO but no MSAA in its gP.hGL. Therefore if you switch off Inspect->Use framebuffers, the display becomes jagged, and A2C transparencies, dithered. The switch-off should be accompanied with a matching reload of AA pixelformat but I haven't yet implemented it.
2. There are glitches with tool window popping on pressing Ctrl when a fancy mode is being rendered and a PP shader used. Ctrl doesn't know what shader to pop up the tool window for.
3. OR now implements per-material culling and two-sided lighting. Use #cull and #bothsides metas directly in the newmtl definitions to cull and two-side-light selected materials. The same metas may be used globally to apply culling and two-sided lighting to the entire model. Note that as per the OpenGL specs, two-sided lighting has no effect on textured meshes in the Fixed Function Pipeline mode.
4. The mods are abundant so please use these sources as the basis for merging. Add your mods (if any) to them but not vice versa.
5. Wherever found, please do not revert my curly-braceless notation back to your funny style. I'm using these pieces of code very often, and too many curly braces make C code readability very poor.
6. Alt+Enter now toggles full screen like in my FBSL shader demos. 8)
Please inform me a.s.a.p. if the mods are working for you as expected. I tested them under my W10 and they worked fine for me.
-
Everything works as you said, and also the things that do not work yet ;)
Thank you very much for this new version my friend !
-
I am glad my mods are working for you too. All in all, this is the long awaited skeleton for ObjReader v3.0. :)
-
Hey Patrice,
Here are some shader patches to avoid app crashes on ATi Radeon GPUs.
Their shitty OpenGL implementation doesn't notify what exactly causes their GLSL compiler to fail. It just silently crashes the entire program. Kept me busy hunting GLSL inconsistencies since early morning... ::)
-
Code updated, thank you my friend !
-
Fine!
I see you lurking here from time to time but you never told me what you think about the five PP shaders that are there in OR so far? ;)
I'm planning to add blurs after I'm through with animated backgrounds.
-
but you never told me what you think about the five PP shaders that are there in OR so far?
To say the truth, i have a hard time to figure how they can enhance the appearence of my existing 3D models.
"Brightness/contrast", i couldn't see any difference between On/Off (indeed very slight)
"Hue/saturation", same as above.
"Sepia", i can see the color change, but if i want a sepia effect i can create the texture accordingly, or change the color settings.
"Vibrance", same as above.
"Vignette", same than for Sepia.
My friend take no offense on my comments, but i rather want FBO effects to serve the existing models with mesh specific like the long awaited, glow, blur, and shadow.
I know that animation will come next, and that would be another great addition.
-
i couldn't see any difference between On/Off...
LOL my friend,
You have probably never used Ctrl to pop up the tool window and adjust your shaders. ;D
... i have a hard time to figure how they can enhance the appearence of my existing 3D models.
This shouldn't be your concern (for the time being -- until we have developed a proper #meta notation to preset them in the .MTL file), but rather the user's concern to tailor their screens to their liking.
Leave that option to them for them to also feel involved in the creative process. :)
... i rather want FBO effects ... mesh specific like the long awaited, glow, blur, and shadow.
"One step at a time"(c), remember? ;)
-
You have probably never used Ctrl to pop up the tool window and adjust your shaders.
Yes, i did with the FBO trial version you sent me on 04-10-2019, but since that time i forgot it, probably because my brain has lost too much neurons, thus being very selective with what it kepts in memory. ;)
-
So now that your neurons are in full working order again, what would you say about the quality of existing PP shaders? :)
-
Your work is highly appreciated, and the quality is very good !
-
Thank you very much for your appreciation! :)
Now watch this and note:- OR debug console (I'm using it instead of zTrace to be able to print CRLF properly)
- state changes in the background list
- FPS rates and GPU usages.
Generally, GPU loads are practically the same as in the FBSL demos, pretty much as I expected.
Now I have to try and- combat animation stalls at texture loading time
- handle background list clicks (i.e. ani shader recompilations).
I'll send you the mods when done.
(The video runs at 30FPS to reduce its size, so it doesn't reproduce the smoothness of shader 60FPS animation)
-
Wow, that really makes a huge difference !
-
Any Shadertoy shader runs as-is in the VS Code shader editor previewer plugin -- including audio! :o
There are plugin sources available on github but the code is written in TypeScript for WebGL and is as difficult to translate to legible C/C++/OpenGL as any other JavaScript/Java junk... :(
-
Is that the link you are speaking about?
https://marketplace.visualstudio.com/items?itemName=stevensona.shader-toy
-
Exactly! Works like a charm in my VSCode but the sources are next to useless... :-\
-
Patrice,
This is to inform you that I'm progressing nicely with the animated backgrounds. I can toggle between non-ani and ani bkgnd modes freely and I can select any ani bkgnds I like from the existing wallpaper list box that I reload with shaders or wallpapers as needed.
All untextured shaders and those that don't have transparent PNGs are working OK though a little too heavy (I'm still using an MSAA FBO where my FBSL demos used a non-AA FBO). But those that rely on 32-bit PNGs (mainly as heightmaps) are looking weird. We probably have substantial differences in our texture loaders.
That's what keeping me so long with my progress. I'm not inclined to stop midway for merging. I'd rather we merge when I find out how to fix the transparency troubles... :-\
-
Thanks for the information.
Abd for the shader animations file name extension, what about .ORS ?
-
Patrice,
The shaders come in a standard plain GLSL format and can run equally well on any OpenGL/GLSL setup that provides them with a set of simple uniform variables. Unlike our uber-shader, they have nothing OR-specific and therefore bear a conventional .FS extension.
I'm sorry but I see no solid reason why they should be supplied with a non-standard cryptic extension.
-
that I reload with shaders or wallpapers as needed.
Why not display shaders and wallpapers mixed altogether in the Listview, and act accordingly to the filename extension ?
-
Because:
1. All preparatory work is done in response to a click to check/uncheck the Animation->Animate background menu in a centralized manner. Reloading is done very quickly both ways completely flicker-less for the list box.
2. Our wallpapers list is already quite long and takes noticeable time to scroll through.
3. When in a certain mode of operation, I prefer to see the palette of tools I can use to control my immediate environment. All irrelevant tools should be hidden not to obscure or distract my view.
Such was my design decision. I hope you'll support it too once started to work with it.
-
A lot of parameters had to be tweaked in the Canyon shader to make it work with the textures almost like my demo did without tweaking. I also adjusted the camera not to fall through the rock walls. Took me several hours of work all in all...
The Caribbean shader (you know, sailing the night sea waters under the moon, stars, and clouds) will have to be tweaked in a similar way to make stars and clouds visible like in the demo/ShaderToy original.
I think we have differences in our standard texture loaders, mainly in handling the alpha layer. Yours turns out to be noticeably thinner to an extent where it breaks ShaderToy's existing coefficients...
-
OK Patrice,
It's merger time. :)
0. Copy the entire \Animated folder into \Resource so that it becomes .\Resource\Animated.
1. Merge the files.
2. All shaders work as expected under my W10 but Caribbean.fs has not yet been tweaked to accept your textures.
3. Almost all shaders also work as expected on my ATi Radeon box except for Tori.fs and OblivionHUD.fs.
4. When MLL_DEV is #defined, OR is automatically compiled as a Win32 console subsystem program where you can use printf() and wprintf() to output your debug messages to the console.
5. You can launch OR-CUI as usual by double clicking its icon. Then it'll pop up its own console window.
6. You can also launch it from the Windows system console, e.g. by D&D-ing its icon there then hitting Enter. In this case, OR-CUI will use the system console for its debug output.
7. In both cases, you can toggle console visibility by pressing Alt+C.
8. When #define MLL_DEV is commented out, OR compiles into a Win32 GUI subsystem program as usual.
9. Last but not least, you do not have to comment out your printf() and wprintf() debug messages from the sources. If there's no console, then those messages are simply ignored.
The mods haven't yet been extensively tested and there may be some glitches present, e.g. if OR cannot read some shader file for some reason. I'll be fixing them as they are revealed.
Your comments and criticisms are very welcome. :)
-
Thanks a bunch my friend !
Will report as soon as i have been able to check it, we have some unexpected visitors coming home right now…
-
Quick report:
Everything is in order and seems to work as espected.
Suggestion:
A specific animation should be selected form the .mtl file, using
#wallpaper animation.fs
or
#wallpaper @animation.fs (when the shader is provided altogether with the model)
no need to use a new meta, the file extension is enough to figure what to do.
Comment:
Several shaders are slowing down OR, while some are very cooperative and seems to have almost no impact.
More to come tomorrow…
Excellent travail mon ami !
-
Thank you Patrice! :)
Hope you slept well. Now it's time to:
1. Delete your existing \Animated folder (delete, don't merge!) and replace it with the one in the zip. (I made changes to textures and shaders but don't remember which and where)
2. Merge the two files in the zip with yours. They contain fixes to make the shaders runnable reliably. The glitch with textures was in fact my own fault with uniform locations. I'm sorry for that... :-[
Now all shaders including Caribbean run as expected.
Don't be too concerned about slow shaders. We'll speed them up eventually using non-MSAA FBOs and better (programmatically) anti-aliased OpenGL canvases.
For the time being, in order to ease up GPU load where necessary, you may use two hacks:
- switch Turbo from 60FPS to 30FPS; and/or
- uncheck Inspect->Use framebuffers; this will make the model aliased but it will bring down the load almost twice, even in the Canyon shader.
I agree to your proposition concerning the animated #wallpaper meta.
Enjoy! :)
-
Everything went fine, thank you!
The current 2dclouds.fs is too jerky even when using the 2 hacks :(
Thinking at loud voice:
I wonder what we could get, if adding support for 2D animation (GIF/PNG).
And also video loop.
-
On my GPU, unchecking Use framebuffers alone yields 25% usage in maximized, and 35% usage, in full screen modes with the clouds running absolutely smooth. However when trying to record the video, I'm also getting some jerkiness though the usage stays practically the same... ???
Please note that practically any shader that uses programmatic noise (real time smoke, clouds, haze etc.) is very likely to be heavy on the GPU.
Re. GIF/PNG, the image files are going to be real huge to keep at least a 30FPS frame rate with sufficient resolution.
Re. video, we probably aren't going to maintain image sharpness competitive with the high quality of rendering the model proper.
At any rate, those aren't the topics I'd be eager to explore any deeper at the moment... ::)
(Sorry for that funny selfie, it was unintentional ;D; but it shows that jerkiness adds only when the camera goes on...)
-
Here is mine…
And this is a new shader that i did try to use, but it fails miserably, what i am doing wrong with it?
And how do you do to retrieve the textures being used on the net?
// Protean clouds by nimitz (twitter: @stormoid)
// https://www.shadertoy.com/view/3l23Rh
// License Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License
// Contact the author for other licensing options
uniform vec4 iDate; // (year, month, day, time in seconds) MLL: year/month/day not used
uniform vec3 iMouse; // mouse pixel coords. xy: current (if MLB down); if vec3 then z: click
uniform vec2 iResolution; // viewport resolution (in pixels)
uniform float iTime; // shader playback time (in seconds)
uniform sampler2D bwnoise_png; // noise in TU0
mat2 rot(in float a){float c = cos(a), s = sin(a);return mat2(c,s,-s,c);}
const mat3 m3 = mat3(0.33338, 0.56034, -0.71817, -0.87887, 0.32651, -0.15323, 0.15162, 0.69596, 0.61339)*1.93;
float mag2(vec2 p){return dot(p,p);}
float linstep(in float mn, in float mx, in float x){ return clamp((x - mn)/(mx - mn), 0., 1.); }
float prm1 = 0.;
vec2 bsMo = vec2(0);
vec2 disp(float t){ return vec2(sin(t*0.22)*1., cos(t*0.175)*1.)*2.; }
vec2 map(vec3 p) {
vec3 p2 = p;
p2.xy -= disp(p.z).xy;
p.xy *= rot(sin(p.z+iTime)*(0.1 + prm1*0.05) + iTime*0.09);
float cl = mag2(p2.xy);
float d = 0.;
p *= .61;
float z = 1.;
float trk = 1.;
float dspAmp = 0.1 + prm1*0.2;
for(int i = 0; i < 5; i++) {
p += sin(p.zxy*0.75*trk + iTime*trk*.8)*dspAmp;
d -= abs(dot(cos(p), sin(p.yzx))*z);
z *= 0.57;
trk *= 1.4;
p = p*m3;
}
d = abs(d + prm1*3.)+ prm1*.3 - 2.5 + bsMo.y;
return vec2(d + cl*.2 + 0.25, cl);
}
vec4 render(in vec3 ro, in vec3 rd, float time) {
vec4 rez = vec4(0);
const float ldst = 8.;
vec3 lpos = vec3(disp(time + ldst)*0.5, time + ldst);
float t = 1.5;
float fogT = 0.;
for(int i=0; i<130; i++) {
if(rez.a > 0.99)break;
vec3 pos = ro + t*rd;
vec2 mpv = map(pos);
float den = clamp(mpv.x-0.3,0.,1.)*1.12;
float dn = clamp((mpv.x + 2.),0.,3.);
vec4 col = vec4(0);
if (mpv.x > 0.6) {
col = vec4(sin(vec3(5.,0.4,0.2) + mpv.y*0.1 +sin(pos.z*0.4)*0.5 + 1.8)*0.5 + 0.5,0.08);
col *= den*den*den;
col.rgb *= linstep(4.,-2.5, mpv.x)*2.3;
float dif = clamp((den - map(pos+.8).x)/9., 0.001, 1. );
dif += clamp((den - map(pos+.35).x)/2.5, 0.001, 1. );
col.xyz *= den*(vec3(0.005,.045,.075) + 1.5*vec3(0.033,0.07,0.03)*dif);
}
float fogC = exp(t*0.2 - 2.2);
col.rgba += vec4(0.06,0.11,0.11, 0.1)*clamp(fogC-fogT, 0., 1.);
fogT = fogC;
rez = rez + col*(1. - rez.a);
t += clamp(0.5 - dn*dn*.05, 0.09, 0.3);
}
return clamp(rez, 0.0, 1.0);
}
float getsat(vec3 c) {
float mi = min(min(c.x, c.y), c.z);
float ma = max(max(c.x, c.y), c.z);
return (ma - mi)/(ma+ 1e-7);
}
//from my "Will it blend" shader (https://www.shadertoy.com/view/lsdGzN)
vec3 iLerp(in vec3 a, in vec3 b, in float x) {
vec3 ic = mix(a, b, x) + vec3(1e-6,0.,0.);
float sd = abs(getsat(ic) - mix(getsat(a), getsat(b), x));
vec3 dir = normalize(vec3(2.*ic.x - ic.y - ic.z, 2.*ic.y - ic.x - ic.z, 2.*ic.z - ic.y - ic.x));
float lgt = dot(vec3(1.0), ic);
float ff = dot(dir, normalize(ic));
ic += 1.5*dir*sd*ff*lgt;
return clamp(ic,0.,1.);
}
void mainImage(out vec4 gl_FragColor, in vec2 gl_FragCoord) {
vec2 q = gl_FragCoord.xy/iResolution.xy;
vec2 p = (gl_FragCoord.xy - 0.5*iResolution.xy)/iResolution.y;
bsMo = (iMouse.xy - 0.5*iResolution.xy)/iResolution.y;
float time = iTime*3.;
vec3 ro = vec3(0,0,time);
ro += vec3(sin(iTime)*0.5,sin(iTime*1.)*0.,0);
float dspAmp = .85;
ro.xy += disp(ro.z)*dspAmp;
float tgtDst = 3.5;
vec3 target = normalize(ro - vec3(disp(time + tgtDst)*dspAmp, time + tgtDst));
ro.x -= bsMo.x*2.;
vec3 rightdir = normalize(cross(target, vec3(0,1,0)));
vec3 updir = normalize(cross(rightdir, target));
rightdir = normalize(cross(updir, target));
vec3 rd=normalize((p.x*rightdir + p.y*updir)*1. - target);
rd.xy *= rot(-disp(time + 3.5).x*0.2 + bsMo.x);
prm1 = smoothstep(-0.4, 0.4,sin(iTime*0.3));
vec4 scn = render(ro, rd, time);
vec3 col = scn.rgb;
col = iLerp(col.bgr, col.rgb, clamp(1.-prm1,0.05,1.));
col = pow(col, vec3(.55,0.65,0.6))*vec3(1.,.97,.9);
col *= pow( 16.0*q.x*q.y*(1.0-q.x)*(1.0-q.y), 0.12)*0.7+0.3; //Vign
gl_FragColor = vec4(col, 1.0);
}
-
Re. your video, yes, it is indeed slow and unacceptably jerky on your GPU. :'(
But it runs more or less OK on mine even with some reasonable model loaded. Probably you'd want to consider upgrading your video card if you can afford it? ::)
Re. the shader code you sent me, it is indeed very, very slow for me even in a windowed no-FBO 30FPS mode where my GPU usage is still 99 to 100%. Yet this furry wormhole is so spectacular I'm going to keep it. :)
Here's the code: (I didn't reformat it so you can easily WinDiff the two offending lines)
// Protean clouds by nimitz (twitter: @stormoid)
// https://www.shadertoy.com/view/3l23Rh
// License Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License
// Contact the author for other licensing options
uniform vec4 iDate; // (year, month, day, time in seconds) MLL: year/month/day not used
uniform vec3 iMouse; // mouse pixel coords. xy: current (if MLB down); if vec3 then z: click
uniform vec2 iResolution; // viewport resolution (in pixels)
uniform float iTime; // shader playback time (in seconds)
//uniform sampler2D bwnoise_png; // noise in TU0
mat2 rot(in float a){float c = cos(a), s = sin(a);return mat2(c,s,-s,c);}
const mat3 m3 = mat3(0.33338, 0.56034, -0.71817, -0.87887, 0.32651, -0.15323, 0.15162, 0.69596, 0.61339)*1.93;
float mag2(vec2 p){return dot(p,p);}
float linstep(in float mn, in float mx, in float x){ return clamp((x - mn)/(mx - mn), 0., 1.); }
float prm1 = 0.;
vec2 bsMo = vec2(0);
vec2 disp(float t){ return vec2(sin(t*0.22)*1., cos(t*0.175)*1.)*2.; }
vec2 map(vec3 p) {
vec3 p2 = p;
p2.xy -= disp(p.z).xy;
p.xy *= rot(sin(p.z+iTime)*(0.1 + prm1*0.05) + iTime*0.09);
float cl = mag2(p2.xy);
float d = 0.;
p *= .61;
float z = 1.;
float trk = 1.;
float dspAmp = 0.1 + prm1*0.2;
for(int i = 0; i < 5; i++) {
p += sin(p.zxy*0.75*trk + iTime*trk*.8)*dspAmp;
d -= abs(dot(cos(p), sin(p.yzx))*z);
z *= 0.57;
trk *= 1.4;
p = p*m3;
}
d = abs(d + prm1*3.)+ prm1*.3 - 2.5 + bsMo.y;
return vec2(d + cl*.2 + 0.25, cl);
}
vec4 render(in vec3 ro, in vec3 rd, float time) {
vec4 rez = vec4(0);
const float ldst = 8.;
vec3 lpos = vec3(disp(time + ldst)*0.5, time + ldst);
float t = 1.5;
float fogT = 0.;
for(int i=0; i<130; i++) {
if(rez.a > 0.99)break;
vec3 pos = ro + t*rd;
vec2 mpv = map(pos);
float den = clamp(mpv.x-0.3,0.,1.)*1.12;
float dn = clamp((mpv.x + 2.),0.,3.);
vec4 col = vec4(0);
if (mpv.x > 0.6) {
col = vec4(sin(vec3(5.,0.4,0.2) + mpv.y*0.1 +sin(pos.z*0.4)*0.5 + 1.8)*0.5 + 0.5,0.08);
col *= den*den*den;
col.rgb *= linstep(4.,-2.5, mpv.x)*2.3;
float dif = clamp((den - map(pos+.8).x)/9., 0.001, 1. );
dif += clamp((den - map(pos+.35).x)/2.5, 0.001, 1. );
col.xyz *= den*(vec3(0.005,.045,.075) + 1.5*vec3(0.033,0.07,0.03)*dif);
}
float fogC = exp(t*0.2 - 2.2);
col.rgba += vec4(0.06,0.11,0.11, 0.1)*clamp(fogC-fogT, 0., 1.);
fogT = fogC;
rez = rez + col*(1. - rez.a);
t += clamp(0.5 - dn*dn*.05, 0.09, 0.3);
}
return clamp(rez, 0.0, 1.0);
}
float getsat(vec3 c) {
float mi = min(min(c.x, c.y), c.z);
float ma = max(max(c.x, c.y), c.z);
return (ma - mi)/(ma+ 1e-7);
}
//from my "Will it blend" shader (https://www.shadertoy.com/view/lsdGzN)
vec3 iLerp(in vec3 a, in vec3 b, in float x) {
vec3 ic = mix(a, b, x) + vec3(1e-6,0.,0.);
float sd = abs(getsat(ic) - mix(getsat(a), getsat(b), x));
vec3 dir = normalize(vec3(2.*ic.x - ic.y - ic.z, 2.*ic.y - ic.x - ic.z, 2.*ic.z - ic.y - ic.x));
float lgt = dot(vec3(1.0), ic);
float ff = dot(dir, normalize(ic));
ic += 1.5*dir*sd*ff*lgt;
return clamp(ic,0.,1.);
}
//void mainImage(out vec4 gl_FragColor, in vec2 gl_FragCoord) {
void main() {
vec2 q = gl_FragCoord.xy/iResolution.xy;
vec2 p = (gl_FragCoord.xy - 0.5*iResolution.xy)/iResolution.y;
bsMo = (iMouse.xy - 0.5*iResolution.xy)/iResolution.y;
float time = iTime*3.;
vec3 ro = vec3(0,0,time);
ro += vec3(sin(iTime)*0.5,sin(iTime*1.)*0.,0);
float dspAmp = .85;
ro.xy += disp(ro.z)*dspAmp;
float tgtDst = 3.5;
vec3 target = normalize(ro - vec3(disp(time + tgtDst)*dspAmp, time + tgtDst));
ro.x -= bsMo.x*2.;
vec3 rightdir = normalize(cross(target, vec3(0,1,0)));
vec3 updir = normalize(cross(rightdir, target));
rightdir = normalize(cross(updir, target));
vec3 rd=normalize((p.x*rightdir + p.y*updir)*1. - target);
rd.xy *= rot(-disp(time + 3.5).x*0.2 + bsMo.x);
prm1 = smoothstep(-0.4, 0.4,sin(iTime*0.3));
vec4 scn = render(ro, rd, time);
vec3 col = scn.rgb;
col = iLerp(col.bgr, col.rgb, clamp(1.-prm1,0.05,1.));
col = pow(col, vec3(.55,0.65,0.6))*vec3(1.,.97,.9);
col *= pow( 16.0*q.x*q.y*(1.0-q.x)*(1.0-q.y), 0.12)*0.7+0.3; //Vign
gl_FragColor = vec4(col, 1.0);
}
Remarks:
-- you should not define any uniform sampler2D variables in your shader code if you aren't using a matching texture;
-- you should use void main() directly avoiding void mainImage(foo, bar) that's in fact just another ShaderToy shader's subroutine a call to which their on-site parser inscribes transparently into their shader's final main() proc that remains hidden from you;
-- all GLSL intrinsic variables and varyings start with a gl_ ... prefix and are accessible from anywhere within that shader. Normally, you wouldn't need to pass them as parameters to the functions within the same shader.
The difference between variables, varyings and uniforms is as follows:
-- variables are used within the given module of a linked GLSL program: vertex, pixel, or geometry shader. Just like in C, they can be module-level or local to a procedure. They are declared the C way: float, bool, int, vec2/3/4 (of floats!), ivec2/3/4 (of ints!), etc.
-- varyings correspond to "extern" variables in C and are used for inter-module communication. They may only be declared at the module level but not within a procedure. Their declaration format is varying float, varying vec2, varying ivec3, etc.
-- uniforms are variables "extern" to the entire shader program and used for communication between your compiled OpenGL program and its compiled GLSL shaders. Communication is done via the OpenGL driver. Their declaration format is uniform float, uniform vec3, uniform sampler2D (for a texture unit), etc.
Re. ShaderToy textures, the most complete set of their textures I was able to find on the net is in the zip attached below.
-
Thanks for the fixup!
From your video, that new shader works much smoother by you, mine is running at 17FPS while in default window mode and 8FPS maximized.
I shall download the latest nVIDIA drivers, version 430.86 from 05/27/2019, to see if it makes any difference ???
-
Here are my FPS rates both at near 100% GPU usage. (Use framebuffers unchecked!)
-
With "Framebuffers" unchecked, it runs at 63FPS in windowed mode, and 28FPS in maximized mode, using the latest drivers.
-
I'm using the 430.86 drivers of the same date.
I'm more concerned about the GPU usage than the FPS rate. We can improve on FPS by optimizing the rendering pipeline, MSAA, material batching, and other such programmatic stuff.
But we can't do anything about the GPU usage because it is entirely determined by the GPU characteristics: clock frequencies, bus width, number of parallel graphics processors, video RAM technology and installed size -- we have no control over those, other than upgrade our cards some every couple of years.
After all, there's not so much time left for our hobbies for us to try and save a few more bucks we won't have time to spend anyway... ;)
-
Even at 75FPS the 2dclouds.fs looks very jerky by me :(
-
Try to uncheck Enable VSYNC in the View menu and see what happens.
It might also be the instability of our home-brewed "clock timer" but I don't really think it can be so bad on your machine. I still think it's more likely it has something to do with the graphics card.
(I have to go out for some cigarettes before they close down for the night...)
-
Have a look at this new one
https://www.shadertoy.com/view/4dKfDd
-
It has noise, it will be slow.
We can try it on though. The Common part of it in its entirety simply goes into the Image section of their shader as sorta "include".
I can work on it when I'm back home in about an hour...
-
Try to uncheck Enable VSYNC in the View menu and see what happens.
Makes no difference.
Playing it full screen on my computer from Shadertoy works just fine, this is the reason why i don't think it is a problem of my graphic card.
The FBS version works also very well in full screen mode :-X
-
For the fun of it
https://www.shadertoy.com/view/XtVGD1
I like these
https://www.shadertoy.com/view/MsVfz1 NeonHex done
https://www.shadertoy.com/view/4sXBRn Luminescence done (gorgeous!)
https://www.shadertoy.com/view/4scfR2
https://www.shadertoy.com/view/Xtf3zn
https://www.shadertoy.com/view/MlscDj
https://www.shadertoy.com/view/ldycRK
https://www.shadertoy.com/view/XldSDs MoebiusObject done
Another clouds
https://www.shadertoy.com/view/lsBfDz TinyClouds done
-
Well, I'm back. :)
Should I work on that newest "dripping" shader? And thanks for the other links, I'll see what can be done about them.
Makes no difference.
...................
The FBS version works also very well in full screen mode :-X
The FBSL demo rendering pipe is much lighter; no MSAA or aniso either in the FBO or on screen, whereas OR runs at 32x MSAA + 8x anisotropy.
Do the Canyon and Pegasus shaders run for you smoothly with Turbo off?
-
I think the Van Damme shader can be re-implemented in ObjReader as a post-processing shader... I like it BTW. :)
-
FPS doesn't shows up when Framebuffer is unchecked.
Do the Canyon and Pegasus shaders run for you smoothly with Turbo off?
Yes, they seem to work fine. (see the attached video)
Perhaps could you send me a copy of your OR's binary for comparison purpose, in case i made an error during merge process.
Note: mine was compiled with VS2017
-
Re. FPS: yes, I observe the missing FPS counter chez moi too. It misses in the non-FBO mode when a non-transparent texture is bound to texture unit 0, but it is seen in all other cases. It must be my glitch with glEnable(GL_BLEND) somewhere. I'll fix it a.s.a.p.
Re. Canyon: no Patrice, your display is far too jerky even with everything off and in a windowed mode. When in a non-FBO mode and full screen, my display is much much smoother, almost like a video, and runs at ca. 50% GPU usage and 60FPS. ???
Can you allow me to attach a 365MB video (w/o recompression to 30 FPS) here for you to see what I'm seeing? ::)
-
No, 365Mb is too large, we are limited to 128Mb per post.
-
Please, send me a copy of your OR EXE for comparison purpose, in case i made an error during the merge process.
Note: mine was compiled with VS2017
-
Hold on a sec, I'm cutting and recompressing the second half of the video for you to see the shader's real speed.
-
OK here's the binary. Recompression of non-beginning part of video goes slowly, and will be finished in ca. 10 minutes.
(I guess I'd rather had it all sliced and packaged with WinRar... ;D ;D ;D)
OK here is all of it in a 720p @ 24fps resolution within a much smaller window.
You'll get the general idea anyway...
-
I deciphered those Tiny Clouds but again, the shader uses that PNG texture (tex16.png) that's obviously not the one they're using on their site. I had to tweak parameters but still the clouds are not exactly as fluffy as the original. Another headache is that the texture must not be mipmapped.
All the other shaders are using mipmapped textures only, and now I don't know how to make OR recognize automatically from the shader code an arbitrary sampler2D's texture needs to be loaded linear rather than mipmapped... ???
-
Morning Patrice,
I haven't yet fully fixed FPS display in Canyon when it runs w/o a model, and there is still conflict of this shader with models rendered in FFP. But I'm halfway there and I made a few fixes for:
-- safer model reload
-- safer clear scene
-- cleaner error handling in case of missing shader file.
The patch is attached below (mods marked MLL 06-10-2019). The binary in my Reply #118 above already has these mods implemented.
-
I don't know how to make OR recognize automatically from the shader code an arbitrary sampler2D's texture needs to be loaded linear rather than mipmapped... ???
What about something like:
lin_texture.png
mip_texture.png (that would be the default in case of "mip_/lin_" omission)
-
:D :D :D :D
Good idea! Actually, m_/l_ would be sufficient and not so heavy for the eyes of the reader...
So, do we agree on that?
Yours truly,
M_L_L_
;D
-
Good idea! Actually, m_/l_ would be sufficient and not so heavy for the eyes of the reader...
OK, i agree on that ;)
Thanks for the OR exe, fortunatly it looks the same than mine when using 2dclouds.fs (there is no merge error)...
-
Thanks for the OR exe, fortunatly it looks the same than mine when using 2dclouds.fs (there is no merge error)...
What can you say about my video?
-
What can you say about my video?
Yours is smoother than mine ???
I shall check the shaders on my Intel 4000, and let you know how it goes...
-
Well, I don't think that would be necessary, my friend.
You will probably be able to take a short nap between two successive animation frames. ;D
You should understand we're at the very edge of technology with those raytraced shaders, in the land of no compromises.
-
Report on Intel 4000
2dclouds.fs, jerky
allseeingeye.fs, perfect
anilight.fs, perfect
auroras.fs, jerky
blueplasma.fs, perfect
bluespace.fs, perfect
canyon.fs, jerky
carribean.fs, perfect
clock.fs, perfect
fire.fs, perfect
heartfelt.fs, perfect
mars.fs, see the attached screen shot
matrixradial.fs, perfect
moabius.fs, perfect
oblivionhud.fs, perfect
oblivionradar, perfect
pegasus.fs, jerky
protean.fs, very jerky
purplespace.fs, perfect
redhot.fs, jerky
seascape.fs, jerky
star.fs, black screen with small moving dots at the bottom
tori.fs, blow up
tunnel.fs, jerky
uroboros.fs, perfect
voronoi.fs, perfect
NeonHex, jerky
Luminescence, jerky
MoebiusObject, jerky
TinyClouds, jerky
end of report...
-
!!! THANKS !!!
The info is very valuable; it helps me spot latent errors in the shaders where nVidia deviates from the stricter GLSL implementation standards of the other brands! :-*
Jerkiness is pardonable on an Intel integreted video chip and the results are quite expectable. But to see jerky 2D Clouds on a modern nVidia?... :o
I've just checked the shaders on my ATi Radeon box. Everything is very smooth (2D clouds and Canyon and other stuff). Of course the GPU usage is considerably higher. The box uses a 2GHz dual core Athlon-II, and Radeon has 2GB of on-board VRAM -- nothing much or special at all. You can see the GPU meter to the right of OR window.
And you know what? On an AMD/ATi PC, your skinned menu panes pop up on the wrong side of their main menu parents (to the left of them...) ;D
-
And you know what? On an AMD/ATi PC, your skinned menu panes pop up on the wrong side of their main menu parents (to the left of them...)
This is a Windows setting. (see menu drop alignment)
https://www.sevenforums.com/tutorials/786-menus-open-left-right-side.html
-
Report on Intel Atom x7-z8700 CPU
1.60 GHz
RAM 2Gb
64-bit
(Windows Surface)
2dclouds.fs, perfect
allseeingeye.fs, perfect
anilights.fs, perfect
auroras.fs, jerky
blueplasma.fs, perfect
bluespace.fs, perfect
canyon.fs, jerky
caribbeans.fs, perfect
clock.fs, perfect
fire.fs, perfect
heartfelt.fs, perfect
mars.fs, jerky
matrixradial.fs, perfect
moabius.fs, perfect
oblivionhud.fs, perfect
oblivionradar, perfect
pegasus.fs, jerky
protean.fs, very jerky
purplespace.fs, perfect
redhot.fs, jerky
seascape.fs, slighty jerky
star.fs, misalignments (horizontal bands)
tori.fs, blow up
tunnel.fs, perfect
uroboros.fs, perfect
voronoi.fs, perfect
NeonHex, slighty jerky
Luminescence, slighty jerky
MoebiusObject, slighty jerky
TinyClouds, slighty jerky
-
Hey Patrice,
Please overwrite your shaders everywhere with those 5 ones from the zip below and see if it cures your renders for them on both of your Intels. (they run fine for me on nVidia and ATi)
If it does, then please correct both your error report tables for me to clearly see what other shaders are still failing. (mark them in red or bold)
TIA
-
Haha, 2dclouds runs for you perfect on your Intel Atom!!! :D
Do you believe now you nVidia may be failing? :-\
-
post #127 updated with new color set to show the status.
-
Thanks a bunch! What about Intel Atom?
-
post #130 updated with new color set to show the status.
-
!!! THANKS AGAIN !!!
The remaining faulty shaders are more difficult to debug in the absence of HW to test on; I'll do it as time permits. :)
Now, one more question (apart from my still unanswered question in post #132).
I'd like to set a task for you related to your wonderful overlays like in the lighting editor. I need time to prepare a decent Technical Specification and a set of mock-ups for you to clearly understand my vision.
I think it will greatly improve our existing UI and be a nice addition to the features in our future OR v3.0.
In principle, do you feel like making another coding effort? I think this time it's going to be an absolute, 100% guaranteed success. :)
-
In principle, do you feel like making another coding effort? I think this time it's going to be an absolute, 100% guaranteed success
No problem my friend 8)
Do you believe now you nVidia may be failing? :-\
It is not failing, just jerky ;)
-
Great! :)
I think I can start with the specs and mock-ups this evening.
Now I have to "go to work" and earn me a couple of bucks for a living. See you again in the evening and thanks a lot for co-operation!
-
I have attached a screen shot of my nVIDIA parameters, to check with yours.
Could you send me these, thanks!
https://www.shadertoy.com/view/MsVfz1 NeonHex done
https://www.shadertoy.com/view/4sXBRn Luminescence done (gorgeous!)
https://www.shadertoy.com/view/XldSDs MoebiusObject done
https://www.shadertoy.com/view/lsBfDz TinyClouds done
I want to see if TinyClouds works any better by me, and i would like to check Luminescence with Medusa.
-
Here they are with the new textures.
Re. TinyClouds, you'll see noticeable dither in the clouds' darker areas. It's due to the noise texture being mipmapped. To temporarily disable mipmapping, goto GLuint glsl_LoadShaderFromFile(...) in shaders.h and:
1. Change line 173 from
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_LINEAR);
to
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
2. Uncomment line 175 and comment out line 176.
3. Recompile to play with Tiny clouds.
4. Do not forget to roll back the changes and recompile again when you're through with that orphan shader.
Please test the shaders also on your Intels and add them to the tables.
-
post #127 and #130 have been updated
On my nVIDIA
NeonHex, windowed + turbo OFF and Framebuffers disabled
Luminescence,windowed + turbo OFF and Framebuffers disabled
MoebiusObject,windowed + turbo OFF and Framebuffers disabled
TinyClouds, windowed + turbo OFF and Framebuffers disabled
Could you compare my nVIDIA settings with yours.
-
Thanks for the updates, my friend!
That's good news about your nVidia. When windowed with both Turbo and FBO disabled, MoebiusObject and NeonHex are still just a tad jerky for me. And BTW, the hexagon glow isn't colored for some unknown reason on my ATi Radeon... The other two shaders are perfectly smooth at those settings.
You should understand that the amount of jerkiness is almost 100% dependent on the HW implementations of our respective graphics chips that vary from model to model, generation, and brand. And even no-name OEM implementations of licensed GPU designs by nVidia, ATi and Intel for one and the same model may significantly deviate from one another... And there's hardly anything I can do about it with the current layout of our MSAA-based FBO pipeline.
The bottleneck is the first 9 lines in void renderScreenQuad() (renderers.h). This is where the MSAA contents of our main FBO are blitted into an ordinary non-AA FBO's texture to be rendered on our screen quads. The texture bound directly to an MSAA FBO cannot be rendered on screen and has to be copied first.
Though hardware-assisted glBlitFramebuffer() runs, on the average, perhaps a hundred times faster than OpenGL's slowest glCopyPixels() API, it is still very highly dependent on MSAA multiplicity (32x in our case). If we exclude MSAA with that blitting stage altogether and use only simple FBOs that we can anti-alias programmatically significantly faster using FXAA and/or CSAA (nVidia only!), then we'll perhaps be able to avoid much jitter in our shaders as well (but of course not in the Protean shader which is ve-e-ery heavy by definition).
What I want to do is to prepare a special test build of ObjReader that will use only simple FBOs regardless of visual AA quality of final render just to see if we're on the right track to eliminate jerkiness...
-
Okay, here's a test build of OR with an ordinary no-MSAA FBO and zero MSAA in its on-screen window. Of course the models look jagged but the low GPU usage leaves us a lot of headroom to try FXAA and CSAA "for size".
I'm observing a dramatic improvement in animation smoothness at 30FPS (Turbo Off) and Use framebuffers On settings. In fact, it's so smooth as if I'm sitting in an iMax movie theater watching Avatar! :D
Simpler shaders run for me at a negligible 8 to 10% usage, and harder ones like Canyon, TinyClouds, Aurora, Pegasus etc., at a bearable 50 to 80% usage full screen, absolutely smooth. The only shader that's perfectly smooth only in a windowed mode is of course Protean. When maximized, its FPS drops to 20, usage skyrockets to 100%, and it starts to jerk heavily.
I'm adding a video to support my words. Try out the binary with the same settings (30FPS/FBO On) on your platforms (the more of them the better) and send me a Canyon video at any resolution but of the same duration, for me to evaluate objectively how good or bad things are on your nVidia.
Don't run Star or Tori as they'll crash your app. Tori is an ugly one and I'll dump it not even bothering to debug, while Star refuses to run in that simple FBO and needs more attention to fix.
-
Everything smooth even in true full screen
2dclouds.fs (CPU 2-3%, GPU 32-35%, FPS 38)
Luminescence.fs (CPU 2-3%, GPU 89-96%, FPS 38)
Mars.fs (CPU 1%, GPU 82-87%, FPS 38)
Protean.fs (CPU 10-12%, GPU 100%, FPS 23)
tinyclouds.fs (the cloud dark parts look granular)
Your hard work deserve my 5-star vote ;)
-
!!! GREAT NEWS !!!
We're now 100% compatible with each other even though you have it all running at 38FPS, which is 1/2 of your standard 75Hz refresh rate.
My main nVidia monitors run at 60Hz (that's where the 30FPS half-rate you're seeing in my video comes from) but my AMD/ATi PC monitor runs at 75Hz as well, and it also displays 38FPS when Turbo is switched down to half-rate.
I've started to experiment with FXAA and I can assure you it won't add more than 5 or 7% usage in full screen. I'm not successful yet because for some unknown reason the PP shader mixes in the screen background color (black, see the screenshot below) where it should only mix the border pixels of screen texture only. But the algo works and edge detection (where the border pixels need to be anti-aliased) is calc'ed correctly. I cannot see any extra load added by FXAA other than at 60FPS full screen, where it is probably less than 5%. The overall usage in the screenie was 40% exactly and perfectly smooth. :)