ObjReader Community
WIP => WIP => Topic started by: Patrice Terrier on July 25, 2018, 10:17:15 pm
-
See this SketchFab link to download a low poly .obj version of the original model from Nika ZautashVili
https://skfb.ly/6A7UX
-
Looks very good indeed. But it uses a different, more modern texture+shader technique especially designed to render metal and plastic surfaces with picture perfect quality. Our ubershader won't be able to render this model so well even with all the necessary textures.
But still I'm eager to see how your model is going to look in the end. :)
-
Looks nice! :)
-
Mike
I have posted the result of my work into the "Sciece fiction" collection.
Warning, due to the size of the project i had to create two posts, to fit everything 8)
BTW: I think that we can support the comparison with the SketchFab version, even if we are not using the latest texture+shader technique.
-
Very good!
But as I said, our conventional OpenGL shader can't render the model's "metalness" realistically enough. We need realtime PBR (physically based rendering) shaders and textures to do that.
-
BTW: I think that we can support the comparison with the SketchFab version ...
Regretfully no, Patrice.
Our current render cannot compare favorably with the SketchFab render the way the materials are currently defined in your .MAT file.
I want to experiment with the model and I think I can come up with much better ObjReader materials.
Note that some of your normal maps have a wrong normal UP direction and thus they exhibit peaks where cave-ins should have been. I don't know how you produced your helmet_4K_bump.png normal map (probably using the original b/w bump map in the nVidia plugin) but I need the same with the normal UP direction reversed. Can you provide me with one so I could experiment a little further?
-
Mike
Here are those (unchanged) that were provided with the original downloaded from SketchFab.
Please remove the attachment once done.
I am looking forward to see what you come with your material file, and reworked textures. ;)
BTW, i made a few enhancements in my personnal version, merging some meshes from the HP FBX version.
-
Thank you Patrice,
Attachments removed as requested.
I already have renders that have considerably better "metalness" than yours. ;) But let me finish before I submit my WIP to you.
I can prove that SketchFab is cheating; their model is rendered with normal maps different from everything that we can download from their site (.obj or proprietary). >:(
-
I turned the kevlar helmet into a metal one. ;)
-
What about these ;D
-
OK Patrice,
I did my best. My task was to render it as close to SketchFab as possible. I did much, but most normal maps are not the ones the site uses for its own renders. My biggest failure was to render the suit in "plastic leather", which is impossible with the current normal and specular maps.
The zip contains a new .MAT file. You can WinDiff it with the old one to see the differences. The zip also contains a lot of new textures needed for the new .MAT file. All of them begin with an underscore, so just unzip them all into your existing R3PU folder. They won't interfere with, or overwrite, the existing ones (some of which have naturally become obsolete).
Enjoy! :)
-
!!! IMPORTANT !!!
Patrice,
Please locate and fix the following materials in your .MAT file (I reworked them):
newmtl cam
Kd 0.25 0.25 0.25
Ks 1.2 1.2 1.2
map_Kd cam.png
map Ks _cam_roughness.png
map_bump cam_bump.png
Ns 512
illum 2
newmtl cam2
Kd 0.25 0.25 0.25
Ks 1.2 1.2 1.2
map_Kd cam2.png
map Ks _cam2_roughness.png
map_bump cam2_bump.png
Ns 512
illum 2
newmtl mask_ad_01
Kd 0.45 0.45 0.45
Ks 0.75 0.75 0.75
map_Kd mask_ad_01.png
map_Ks _mask_ad_01_roughness.png
map_bump mask_ad_01_bump.png
Ns 512
illum 2
newmtl mask_big_lock
Kd 0.45 0.45 0.45
Ks 0.75 0.75 0.75
map_Kd mask_big_lock.png
map_Ks _mask_big_lock_roughness.png
map_bump mask_big_lock_bump.png
Ns 512
illum 2
newmtl mask_gen
Kd 0.4 0.4 0.4
Ks 1 1 1
map_Kd mask_gen.png
map_Ks _mask_gen_roughness.png
map_bump mask_gen_bump.png
Ns 512
illum 2
newmtl mc_block
Kd 0.75 0.75 0.75
Ks 1 1 1
map_Kd mc_block.png
map_Ks _mc_block_roughness.png
map_bump mc_block_bump.png
Ns 1024
illum 2
newmtl helmet_logo
Kd 0.75 0.75 0.75
Ks 1 1 1
map_Kd helmet_logo.png
map_Ks helmet_logo.png
map_bump helmet_logo_bump.png
Ns 256
illum 2
and add a few more textures from the below zip to your R3PU folder!
-
Patrice,
The mc_block mesh contains a few tris that either i) have very bad normals that the current normal map makes too prominent to let them stay as they are, or ii) aren't textured at all (miss tex coords completely or have degenerate tex coord triangles).
Can you please try and fix them in your C4D?
-
My friend
Thank you very much for your contribution!
I shall make it the official version, because it is the closest to the original.
I have also reworked a personnal version, with a few more meshes and extra materials, perhaps it will co-exist with the official one ;)
Added
I shall see what i can do for the mc_block.
-
About the mc_block, the only way i can do it, is to recreate the mesh from scratch :(
-
Apart from bad poly configuration in and around its oval recesses (obviously due to wild decimation), the mc_block mesh contains duplicate surfaces that are causing z-buffer fighting. This is the reason why its surface looks more or less passable with OpenGL automatic lambertian smoothing but fails as soon as a normal map is added...
Theoretically I could export this mesh, clean it of its duplicate surfaces, re-normalize in AkkuTrans, and import back into the model. This could improve its looks under the normal map. But I feel too lazy to engage myself in this affair. Shouldn't we rather leave it as is? This isn't the only mesh with duplicate surfaces; there are a few more minor mesh parts that could be improved on... But I don't want to spend my time on them because it's going to be too laborious for very little profit. ;)
-
I have worked on the exported FBX HP version, and it has the same problem, mailing because of slight point misalignment, but there is no duplicate surfaces. I already spent several hours trying to work around this problem >:(
Just in case, i have attached the original FBX block group.
-
... there is no duplicate surfaces.
Our model does have a duplicate backfacing surface on the other side of mc_block. Please see the picture.
[UPD] And no, your FBX export also has backfacing polies and z-buffer fighting. Moreover, it has several layers of offending polygons, so that face culling in ObjReader doesn't help get rid of them completely. :(
-
Here is the best i could…
(i have reworked totaly the mc_block, see b1 to b6 in the mtl file, and the matching png)
And the link to download the reworked project.
http://www.objreader.com/download/demo/r3pu.7z
-
Thank you very much Patrice,
You did a great job! :)
But if you don't mind, I will rework the b1 textures. Your mc_block looks like it's brand new from the factory. But that's a weather-bitten robocop SOB taken for an overhaul right out of the street riot, so its parts should look worn-out, scratched, and unpolished.
I'm also planning to make the uniformly colored textures of other b parts much, much smaller. This isn't going to change their coloration and glister but their VRAM footprint together with their mipmaps will thus be significantly smaller. "Small is beautiful", you know, unless it impairs quality, which in this case it doesn't. :)
-
For the fun…
-
For the fun…
:o
!!! KOOL !!! POSITRONIC BRAIN RULEZ !!! ;D
(https://qph.fs.quoracdn.net/main-qimg-4144a5990d7d3eea4e79d83cf662168b-c)
OK,
So catch a new set of _bX_XXX textures and please fix the following slightly reworked materials:
newmtl b5
Ka 0.15 0.15 0.15
Kd 0.75 0.75 0.75
Ks 0.75 0.75 0.75
map_Kd _b5.png
Ns 512
illum 3
refl chromium.png
newmtl b4
Kd 0.75 0.75 0.75
Ks 4 4 4
map_Kd _b4.png
Ns 96
illum 3
refl _dark_chromium.png
newmtl b1
Kd 0.55 0.55 0.55
Ks 1 1 1
map_Kd _b1.png
map_Ks _b1_roughness.png
map_bump _b1_bump.png
Ns 640
illum 2
The _b1_xxx textures have been mainly Free Transform'ed by me in Photoshop from the original bump and roughness maps. I think they give a better sense of wear and tear. :)
-
Ok, done, thank you.
Do you see anything else to change before i update the official version?
I think i should add my police_logo mesh, see the attachment before i add wear and tear to it ;)
-
Do you see anything else to change before i update the official version?
Yes, there's a strange patch on the back of the neck just above the battery. It isn't very noticeable but it does look like there's a severe z-buffer fighting going on there. (see top picture)
I think i should add my police_logo mesh ...
Let's try and see what it looks like when added.
... see the attachment before i add wear and tear to it ;)
The original render's roughness texture displays it as a shiny transparent decal (sticker) glued on top of the black paint that covers the steel helmet. (see bottom picture)
Our conventional diff+spec+bump system can't reproduce it in a common mesh, and that's why I corrected the roughness texture to show the logo as an ordinary white paint-on-black paint screen print. I think a separate transparent illum 2/3 mesh with a high Ns value may display your new logo as the original decal and preserve the metal paint scratches beneath it to simulate general wear and tear. :)
-
I have updated the official version with the latest changes.
I hope i didn't forget anything…
-
Thank you, Patrice!
Nothing seems forgotten; in fact, there are some extra (older) textures not used in the final model. :)
Did you mean your logo to look as if it were a paper sticker glued on top of a metal cylinder?
-
Yes, because as you guess it right, it is a sticker ;)
Do you know the name of the extra unwanted textures, as i haven't checked them myself (busy working on the animated version).
BTW, i have also updated the screen shots of the official version.
-
BTW, i have also updated the screen shots of the official version.
BTW you could have also updated the names of the persons who contributed to the reworking of the model, in the credit.txt file. ;D
-
Do you know that, indeed, there is a brain under the helmet.
-
Reworked by the ObjReader team
Perfect! Thanks! :D
Do you know that, indeed, there is a brain under the helmet.
Awesome!!! :-* A positronic police robot evolves into a genuine bionic robocop! :o
P.S. Please let me have the model for checking before you update the official release!
-
You know what Patrice,
Objector currently uses a slightly different uber-shader to render to texture for subsequent vignette post-processing. It seems to treat the normal maps a little differently and it has no brightness clamping, therefore its final renders may be overbright if needed.
As a result, Objector's bumps seem to be more correct than those in ObjReader... ???
Here's how the bumps look generally in Objector (top) and ObjReader (bottom) in the upper picture. Your comments are welcome.
[UPD] As per the lower picture, it looks like Objector can render microscopic bumps also somewhat better than ObjReader:
-
Re: the brain
What about adding a few little varicoloured emissive LEDs to the brain mesh? 8)
-
Mike
Obviously , Objector's bumps look more correct than the one used in ObjReader.
-
As i said objector's bump looks better.
I will need some time to investigate if better bumps are a side effect of post-processing or superior math in Objector's fragment shader. I will report back on this issue in a couple of days.
See the attached video(s), using animation.
Wow!!! 8)
What about the "human" brain you teased me with earlier?
-- Can this ball-shaped artificial brain be made larger to fill in the empty space in the skull? Can a few multi-colored light-emitting diodes (LEDs) be added to the golden "lock" plates and rotate together with the whole thing?
-- Why isn't the lower jaw yellow any more?
Press Ctrl F5 and look at the second animation video ;)
No, I like the ball brain better than the diamond one, just please make it somewhat bigger and add the LED's if you can...
-
P.S. Please let me have the model for checking before you update the official release!
Here is the link to the cleaned up version (i changed the name of the textures, and removed the images not used).
http://www.objreader.com/download/demo/r3pu.7z
-
the human brain is static (no animation)...
-
Here is the link to the cleaned up version ...
Patrice,
Please export the existing lower jaw mesh with its normal and text coord data from your C4D as a separate OBJ model and send it to me.
-
The lower jaw and the bone skull i am using in my personnal version are not the same than those used in the official version (mine are based on the FBX HP version, and a different set of UVW mapped textures)
Here is a video to show you the static brain with burning fire emission...
-
1. Your latest cleaned up version has a few deficiencies. Please don't upload it as an official version yet.
2. Your hi-res "human brain" model looks better than the "ball brain" model to me. Can you consider adding a few semi-transparent tubes rising from the brain metal "pedestal" right into the brain as if feeding it with the vital liquids? If the tubes are segments of a torus and the brain itself isn't transparent, then you can also add a round mesh of small emissive particles (a "synaps" of sorts) that could rotate inside its respective static tube concentrically with it thus emulating electric pulses flowing up from the "pedestal" and into the brain... ::) 8)
-
1. Your latest cleaned up version has a few deficiencies. Please don't upload it as an official version yet.
Yes, i found a few of them (i have too many versions with different materials) :-[
-
Is that what you have in mind?
-
1. Exactly!!! Yet balls should not be big balls but sort of smaller spikes or sparkles of various shapes, sizes and emissive colors coming at irregular intervals... And the number of "tubes" should be bigger and they should be of different thicknesses. 8)
2. I didn't like the existing low-poly jaw at all. So I reworked the textures and material again. Now the jaw looks as if it is made of yellowish die-cast metal powder, and its texture seams are almost invisible. See the attached picture and let me know if you agree, and if yes then I'll send you my fixes in a couple hours. (need to go out to buy some cigarettes)
3. You took the wrong normal map for the zipper. The one you're trying to use is rubbish while my (underscored) version was correct.
-
For the jaw and the skull, i am using the one attached to this post.
-
Both jaws are OK, geometry- and normals-wise, but the old bump and specular maps are bad. I include my new bump and spec maps for the low-poly jaw in the zip, and I also add a correct bump map for the suit zipper. Please use them with the following material that I fixed to match the new maps:
newmtl skull_jaw
Ka 0.25 0.25 0.25
Kd 0.64 0.64 0.64
Ks 0.5 0.5 0.5
map_Kd skull_jaw.png
map_Ks skull_jaw_ks.png
map_bump skull_jaw_bump.png
Ns 96.078
illum 2
-
I'd be glad to have it, Patrice!
The result isn't so bad. The tubes must be seen through the face plate, and the balls should fly up like bubbles. And the tubes should then be emissively colored to simulate fluorescent fluid flow inside them... ::)
(https://i.pinimg.com/originals/a7/b8/c8/a7b8c8e9d4e9ef0d2bef0d417075494b.gif)
-
DL'ed OK.
Looks great for starters... There can be several concentric rings of bubbles of different sizes and speeds in the same tube to emulate random bubble flow...
[UPD] The other, left-side half of torus can be made fully opaque to hide the bubbles flowing wrongly downwards...
-
Patrice,
I need two more separate torus meshes concentric with the existing torus: one of slightly smaller torus tube diameter, and the other one, of slightly larger one, so that the smaller one would fit tightly inside the tube of the existing torus and together they would fit tightly inside the tube of the larger one. The both toruses should be nicely normilized and equipped with tex coords like the existing one.
I also need a transparent texture that should emulate veritably an air bubble to be used instead of the pearl-like glistening gem balls currently rotating in the torus. (can there be a circle of 2D billboards instead of balls if it is impossible to emulate a 3D ball air bubble with a texture?)
Can you do that for me, please?
(I'm going out for the whole day tomorrow on Thursday but I'll be back home on Friday and I could use the above assets then, if of course you agree to help me out with them)
-
Patrice,
FYI: the innerpart_ks.png texture you're using in your mat files doesn't exist because you forgot to rename its current sibling innerpart_roughness.png accordingly.
Traditionally in the industry, positronic robotic brains have always been drawn in neon-glowing cyan. What would you say aesthetically to this version:
-
For the 2d billboard texture maybe we can use the one of my buble plugin, that is also the same used in my charting demo.
For the concentric torus tube a quick draw would help me to better figure what to do.
About the Ghost rider color it was just the one from my first brain projject without animation but of course we can use anther color like yours with the animated version.
Note, i am typing this message from my android phone., not as easy than with a regular keyboard 😯
-
Patrice,
My English seems to be letting me down. :)
-
Ok, i better figure it now, and i shall do it quickly.
(a good draw is better than a thousand words ;) )
I have attached the Bubble texture i am using with my BB plugin.
And of course
https://www.google.com/search?hl=en&biw=1259&bih=628&tbm=isch&sa=1&ei=PLtiW5nkL8qKlwTksaT4Dw&q=bubble+texure&oq=bubble+texure&gs_l=img.3..0i10i24k1.4587.6196.0.6931.6.6.0.0.0.0.87.444.6.6.0....0...1c.1.64.img..0.6.439...0.0.FAhC9uNA-5k
-
can there be a circle of 2D billboards instead of balls if it is impossible to emulate a 3D ball air bubble with a texture?
How would you rotate the 2D billboards into OR?
-
Example of animation with fluid and bubble.
:D :D :D A-a-a-a-a-a-a-a!!! Excellentissimo!!! :D :D :D
Are those billboards or 3D balls?
Can you send me this setup as a separate "brain unit" model to spare the 45 seconds of loading the entire robocop? I would love to play with it myself... :)
Can I also have the two toruses, please? I'll split the outer one vertically in two and use its left half as an opaque cover for the transparent torus tube. I'd like to see how it would look with the downwards flow hidden from view...
(Was it your real voice in the video? ;) )
-
Here is the bb.obj to ease your test.
The voice you hear in the video, is the internet radio i was listening ;)
Note: Even trying hard for a couple of hours, i was unable to use billboard with it
-
Here is another solution if you only want to see the up fluid flow.
BTW: Looks like, we can't use "Save to image" while an animation is playing...
-
Here is another solution if you only want to see the up fluid flow.
It isn't "another solution", it is "another part of solution" because I'd actually like to see several tubes "feeding" the brain. Probably of different diameters and colors and bubbles. :)
-
I made a few changes to the materials of my personnal version, see if you can say what has been changed :)
-
-- Different custom wallpaper
-- Brain color reverted to infrared
-- Torus tube has seemingly opaque casing (outer torus or yet one extra outer torus?) -- full on the left, partial on the right. At least descending bubbles are not seen through it any more while brain is... (???)
-- Formerly steel innerpart turned semi-transparent (:o)
8)
-
- The color of the "mask_gen" mesh has been reworked to better match the original.
- The helmet border mesh has been made thiner, because it was going inside of the "bone_skull"
- I have added a new opaque "tor_tube" mesh.
I have been playing with a few more bubbles, see the attachments.
-
Small changes to apply to the source code to use "Save" and "Print" while in animation mode.
In ProcessMenu
case MENU_WALLPAPER:
if ((long) SendMessage(GetDlgItem(hWnd, IDC_ANIMATION), BM_GETCHECK, 0, 0) == BST_CHECKED) { gP.nRotation = 0; } // PAT 08-04-2018
gP.capture = USE_FILE; // 05-22-2015
gP.redraw = -1; // Redraw the OpenGL scene
break;
case MENU_PRINT: // 05-22-2015
if ((long) SendMessage(GetDlgItem(hWnd, IDC_ANIMATION), BM_GETCHECK, 0, 0) == BST_CHECKED) { gP.nRotation = 0; } // PAT 08-04-2018
gP.capture = USE_PRINTER;
gP.redraw = -1; // Redraw the OpenGL scene
break;
In gl_DrawScene
if (gP.capture) {
if (gP.capture == USE_PRINTER) {
gP.capture = 0;
SendToPrinter();
} else {
gP.capture = 0;
SaveToImage();
}
if ((long) SendMessage(GetDlgItem(gP.hMain, IDC_ANIMATION), BM_GETCHECK, 0, 0) == BST_CHECKED) { gP.nRotation = -1; } // PAT 08-04-2018
}
-
Code fixed as advised, thanks!
-
- The color of the "mask_gen" mesh has been reworked to better match the original.
No way.
The mask_gen material should be identical to the surrounding material. (see top render from SketchFab)
Our mask_gen has a material similar to its surroundings but we're using roughness maps as specular maps, and therefore our materials appear as glossy metal rather than dull metal. (see bottom render by ObjReader) But it still looks like a veritable metal of similar physical characteristics.
From what I can see in your render, your mask_gen looks as if it is blued like a handgun barrel similar to the objective lens hoods, which isn't "original" at all IMHO.
-
That is my personnal mask_gen version, and that is the way i want it, the official version is kept unchanged. :)
See the original blender screen shot of Nika Zautashvili attached to this post.
https://www.artstation.com/artwork/xggaR
-
Indeed the look of the LP SketchFab version and the HP Blender's are quite different.
-
Exactly!
Thanks for the original links! The Blender renders use absolutely different lighting (lit from top). The helmet and face metals seem to be all blued; the skull metal is of a different darker tint and glossiness. And the model uses a full set of ambient occlusion maps that we don't have at all.
Yet our render looks very good too and also very close to SketchFab. :)
[ADD] As a matter of fact, we can also add a 4th directional light source -- top-to-bottom. 8)
-
As a matter of fact, we can also add a 4th directional light source -- top-to-bottom.
Indeed that would be very handy ;)
-
Indeed that would be very handy ;)
I'll see what I can do. :)
BTW where did you get your HP version, Patrice? The .blender file Nika offers for free is extremely low poly, far lower even than SketchFab... :-[
-
I am using the exported fbx version from blender.
This one uses hyper nurbs.
And very detailed individual meshes
-
And very detailed individual meshes
This is what his .blender file looks like, and naturally its .FBX export too. :o
:-\
-
!!! AHA !!!
By applying render-time modifiers to the base meshes while doing a direct .OBJ export from Blender, I got a near 1GB large very high-resolution .OBJ file with perfect geo and normals and an associated material file but so far without any textures. There must be some obscure manipulations somewhere though to force Blender to dump the .blend model's built-in texture payload too...
8)
-
Here is a link to the textures i have been able to export from Blender in HP mode (380 meshes for the fbx version)
http://www.objreader.com/download/demo/_textures.zip
-
Wow! Dastisch fantastisch Patrice!!! ;D
These contain the AO and cavity textures we can also use in our shader! I still wish I can export the textures (at least diffuse ones) directly from the .blend model and into the .MTL file myself...
... (380 meshes for the fbx version) ...
The .OBJ export seems to contain a few null meshes (without any visual representation), so the actual usable mesh count may well be 380, rather than 388, meshes all in all.
-
Psychotronic revisited.
-
Aha! The brain pedestal has become completely opaque, and the jaw, transparent. :)
-
Here is something new i have been playing with in c4d (converting a 2D texture into 3D mesh).
Good for bump mapping replacement…
-
Ahahahahahaha! That's cool! :D
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. :)
-
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
-
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. :-[
-
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 :)
-
Cool! :D
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. 8)
-
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) ?
-
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. 8)
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. :)
-
Please see the new Buster Drone model into the WIP section.
-
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...
-
Mike
Please try with the RAMJET model.
Added
That's the same problem we had a couple years ago ;)
-
i can see a huge difference with my personnal set of textures :)
Yes, and I like it! :D
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.
-
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?
-
http://www.objreader.com/index.php?topic=133.msg2611#msg2611
-
Check also with FALCON MILLENIUM.
-
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. ;)
-
I can almost, but not entirely, correct the Ramjet model by using the epsilon of 0.000001, rather than 0.0001, in the (bi)tangent calc. But for the life of me I cannot correct the side planes in Millenium Falcon!
I do not understand your "load/save the model into accutrans" suggestion; there's too little info in it for me. Pure load/save of .OBJ file yields nothing because the file is saved as-is except for the .MAT file. Forcing the AT clone to work with the original .MAT file reveals the glitch. Even if I recalc the hard and/or (not very good) soft normals in AkkuTrans and save them to the clone, using the original .MAT file still reveals the glitch. Which means the model still has some plane normals our (bi)tangents can't cope with!
They can cope only with the (very poor) normals recalculated for the both models by ObjReader itself... :-\
-
Tell you what Patrice,
Both Ramjet and Millenium Falcon .OBJ files refuse to be imported in my 3ds Max'es (I have two of them: 32- and 64-bit 2010 and 2016 versions) for re-triangulation. The editors report bad vertex/normal/texture indices. If you exported them as OBJects from your C4D, I regret to say your C4D object exporter is broken.
At the same time, the much smaller test file you had supplied me with (http://www.objreader.com/index.php?topic=133.msg2614#msg2614) earlier does load successfully in 3ds Max and when re-triangulated, exports to a new 1.5 times smaller .OBJ file with perfect normals that both Objector and ObjReader display flawlessly with their existing (bi)tangent calc. :)
This makes me think that your C4D object exporter is unreliable and may continue to let us down in some future cases without prior notice. What was the original format of these two models? If I can read it with my 3ds Max importers, I suggest we re-triangulate and optimise them first in 3ds Max and then you re-work them again in your C4D to bring them to their ObjReader-renderable state. I think the model files may get down to nearly half their current size in the process.
This way we will also do away with this horror we're seeing which is not our renderers' fault at all. ;)
-
This is what my 3ds Max did fully automatically with the smaller test file. The two black planes and one trianle at the bottom are backfacing geometry that 3ds Max, as any other 3D editor, cannot correct automagically.
Do compare it against the original smaller test file at the link above and feel the difference. 8)
-
Were the Ramjet and Millenium Falcon originally provided as C4D format files? As far as I am aware, neither AkkuTrans nor any other 3D editor I know of have C4D proprietary file format importers. ;)
-
Here is a link to the original Ramjet from Anders Lejczak
http://www.colacola.se/expo_alphacentauri.htm
-
To avoid breaking the existing models, i think that the best solution is to keep using the old bump as the default, and use a new mtl option for the new one.
-
Never! We will never EVER use those sloppy shitty 4-bytes-off-the-target bumps again!!!
We are going to use structurally correct tangent coord offsets and our awesomely cool conventional, parallax, and steep parallax bumps (with optional bent normals) forever in our future work till the day we die! 8)
(And if I ever see this glitch again in some future model, this is going to be a 100% sure indication you just sabotaged your homework... ;) )