More WIP on R3PU

[Michael Lobko-Lobanovsky]

Ahahahahahaha! That's cool!

Of course it cannot replace texturized bumpmapping; it is too rough for that because it results in vertex based, rather than per-pixel, rendering. But that's exactly how 3D terrains are generated statically from grayscale terrain "maps" or programmatically in real time in applied 3D game dev.

This method applied programmatically and invisibly to the viewer can also be used to generate ("bake") ambient self-occlusion maps similar to those that were used in genuine R3PU Blender renders. They are available in your texture pack you pointed me to a while ago.

[Patrice Terrier]

But that's exactly how 3D terrains are generated statically from grayscale terrain "maps" or programmatically in real time in applied 3D game dev.

That is also almost the same to what i am doing in my Pix3D project here
http://www.objreader.com/index.php?topic=18.0

[Michael Lobko-Lobanovsky]

Dear Patrice,

I'm currently working on why Objector generates better bumps than ObjReader.

As it happens (it's been years so I have forgotten it), Objector uses a different fragment uber-shader that allows for parallax/steep parallax bump mapping for superior quality bumps, especially if shadow and hight maps are used along with the usual diffuse/normal/specular maps. Apart from that, its drawProgrammablePipeline() function is written entirely in assembler to yield the maximum speed possible. It uses five texture units instead of ObjReader's current three.

Since x64 MS VC doesn't support assembly, I can't use Objector's PPL renderer verbatim. I have to port it to C. I wrote it directly in FBSL low-level asm and I don't have any ready-made C prototype.

I'll send you my ObjReader renderer fixes as soon as I'm through with porting and preliminary tests. Please be patient; I'm not feeling myself quite well in this oppressive heat and humidity (up to 90%) we're currently having here in Minsk.

[Patrice Terrier]

I'm not feeling myself quite well in this oppressive heat and humidity (up to 90%) we're currently having here in Minsk

We also have an oppressive heat, like most of the northen hemisphere, fortunatly the nights are cooler by me, because i am living in the country side, and there is no asphalt concrete arround me to keep the heat.

As you can see on the attachment i am still playing with robocop 

[Michael Lobko-Lobanovsky]

Cool!


Well,

So far so good. The bumps are now OK visually, both macro and micro ones. And now ObjReader also enjoys parallax/steep parallax bump mapping with up to 5 TU's, pretty much like Objector.

[Patrice Terrier]

Good job my friend!

I have another c4d model (from SketchFab) with AO, emissive, metallic, normal, albedo, and roughness textures.
Is that something you would like to play with (once converted to .obj) ?

[Michael Lobko-Lobanovsky]

Here's a precompiled binary and a couple of steep parallax models for you to play with in the meantime.

I'll be adding the 4th top-down directional light and then we'll merge the mods when completed.

Please check also the other models from your collection and tell me your impression.

I have another c4d model (from SketchFab) with AO, emissive, metallic, normal, albedo, and roughness textures.
Is that something you would like to play with (once converted to .obj) ?

Yes please,

And note that a set of original textures is an absolute must.

[Patrice Terrier]

Please see the new Buster Drone model into the WIP section.

[Patrice Terrier]

Bump comparison

Top - before

Bottom - after

i can see a huge difference with my personnal set of textures

Added:
On some of the existing models it looks a little too strong, do you think it would be possible to use a new meta command to select the new one rather than the (default) old one ?

Doing more test with the existing models...

[Patrice Terrier]

Mike

Please try with the RAMJET model.

Added
That's the same problem we had a couple years ago

[Michael Lobko-Lobanovsky]

i can see a huge difference with my personnal set of textures

Yes, and I like it!

And now the robocop's plastic leather suit renders more or less veritably.

On some of the existing models it looks a little too strong, do you think it would be possible to use a new meta command to select the new one rather than the (default) old one ?

Please read my Brief Intro to Simulated 3D Bumpiness in the Tips & Tricks section.

The precompiled ObjReader I sent you uses steep parallax bump mapping, the strongest one of the three even if the hight map isn't available in its disp(lacement) map channel of this particular model's materials. I think we can introduce two alternative params for the map_bump directive and thus have three choices: conventional (old) when no param is used, parallax param for ordinary parallax mode, and steep for enhanced steep parallax mode.

Bent normal maps may be used on default without any specific parameters even without additional height (a.k.a. displacement) map. Sufficient height information is already pre-baked into the bent normals themselves.

[Michael Lobko-Lobanovsky]

Mike

Please try with the RAMJET model.

Added
That's the same problem we had a couple years ago

Yes, this model tends to give us some constant PITA.

My observations:

1. The bumps are magnificent, aren't they?

2. The model lacks some bump and specular maps.

3. There's absolutely no problem with this model in Objector.

4. I can't recollect now what exactly was causing this glitch in the past and regretfully there are no notes on it in the code. So I'll need some time to re-investigate the matter.

What about other models? Any more of similar glitches anywhere?

[Patrice Terrier]

http://www.objreader.com/index.php?topic=133.msg2611#msg2611

[Patrice Terrier]

Check also with FALCON MILLENIUM.

[Michael Lobko-Lobanovsky]

Damn!     (Thanks a bunch for the leads though)

I reverted the tangent/bitangent offset in the render proc to what it should be according to the vertex structure prototype, and that corrected the faulty bump mapping we had in ObjReader all this time.

But it again brought about this glitch and I again tend to think that something must be evidently wrong with structure alignment or packing... The C language has some data alignment peculiarities that occasionally bring about similar phantom bugs. But either way, they have nothing to do with Q_fabs or epsilons or any other calc speed enhancers we have throughout the code...

And forget about the FFP Patrice. We're well past the short panties of our immediate mode childhood, my friend.


P.S. Can it be that our tangent/bitangent calc loop generates just one or two per vertex results fewer than it should so that not all the vertices are covered?  OTOH Objector uses the exact same C code and doesn't display such artifacts...

Anyway, I'll be thinking about this problem trying to find the remedy. It must be something so obvious that I can't notice it right under my nose.