ObjReader Community
WIP => WIP => Topic started by: Patrice Terrier on September 04, 2018, 10:22:55 am
-
I did find a nice (and clean) version of the Oblivion bubble ship model by T.Flex.
https://sketchfab.com/models/c1e71fbff8b346d48f7f16f6f30dc11e
-
Cool though not very exact, material-wise. :)
Now the problem is where do we get Tom Cruise to pilot it? ;D
(Tom Cruise (http://steplont.blogspot.com/2015/10/3d-model-tom-cruise-head.html))
Mike
-
Here is one that shouldn't be too hard to fit within the cockpit.
And you can even use the TOM CRUISE head if you want ;)
-
Here is a first reworked WIP version, with duplicated meshes, and glass artefacts removed.
The mtl file is the one directly exported from C4D, with just the global #alphatocoverage directive added to display correctly the transparent cockpit parts.
-
Thanks for sharing the model!
I'm seeing absolutely no artifacts on the cockpit glass. Why should we use A2C here at all?
-
I'm seeing absolutely no artifacts on the cockpit glass. Why should we use A2C here at all?
because i have removed them, some parts of the glass were overlaping the cockpit cage.
But we can remove A2C
BTW i did put the pilot inside of the cockpit (now i am looking for a new head)
-
:o
Oblivion Bubble Ship Take-Off (https://www.youtube.com/watch?v=Mznwd9I-kM0)
Oblivion Bubble Ship Real Materials & Assy (https://www.youtube.com/watch?v=K-yhavpntp8)
8) ;) :)
-
I can hardly help you with this model, my friend, but just in case you would like to fly your bubble ship over some post-apocalyptic earth landscapes, I made a few fair resolution screenies (adjusted to 1920x1080 px) from the movie. I think some of them might go well as the model wallpapers. :)
Just please remember the movie bubble ship had the exact same finish that drone 166 had.
-
Currently i am reworking the meshes, and creating a new set of textures while playing the movie to better match the original (no more yellow color), and i am also adding a few rotations here and there...
-
What i have been able to achieve so far...
-
Patrice,
This looks AWESOME!!! 8)
:o
-
Still a WIP, but for safety purpose, it is better to have a copy elsewhere ;)
-
1. This IS awesome!
2. Hehe no, the console doesn't seem to have UVs suitable for the console_board texture.
3. The tank and main hull textures have different UV scale. Both should have the scale of tank texture. (scale up the main hull UV tex unwrap to be twice bigger along both U and V)
4. If you switch off textures and turn the engine axle invisible, you will see some elliptic part that performs presumably illegal rotation.
-
Probably this set of screenies can aid your texturing effort. :)
-
Here is another backup...
-
Almost all of the model exterior that required AO has been occluded successfully. :D
-
Almost all of the model exterior that required AO has been occluded successfully.
The problem is that the real model is build from composit material, rather than metallic.
It looks more like the white body of a glider plane.
Here is another build with a bunch of changes…
-
That's because we're working with per-material constant Ns. The big idea behind material metalness/roughness (that's the PBR way of rendering things) is per-pixel variable Ns that's hardcoded in its own map_Ns.
I'm currently looking into this technique closely and I think I'll soon be able to come up with a shader that can handle PBR models without having to rework/adapt their texture maps first.
-
In the last build, i think i have removed all the watermarks from the bubble_body/engine texture set, however if you could inspect them closely just to make sure they have been all cleaned up, 4 eyes being better than 2...
-
That's a very nice-looking "moonlit" rendition of the model. :)
(I can't see any offending watermarks in the texture color/alpha channels.)
Yet the model should be AO mapped. I can't enjoy bare renders now that I have an almost complete set of map_Ka textures. I'm appending them below in the zip for you to use too. You can derive their respective meshes in the MTL file from the texture names.
Note that to be able to see AO, the material needs to go through the normalmap branch of PPL. To this end, the AO-ed materials should have either their own normal map or utilize the neutral_bump.png dummy explicitly. Note also that my current ObjReader renders AO much more vividly than yours because yours uses it predominantly in the ambient material+light component while mine shares it equally between the material+light ambient and diffuse components.
-
That's a very nice-looking "moonlit" rendition of the model.
Yes, the rendition must match closely the ambient lighting of the wallpapr being used.
Did you notice the new red light animation, the new rotor rotate effect, the new rotule and legs texturing, and the reworked jet propulsion.
Now i have to figure what to change with the legs to have a real flying version :-\
Thanks for the new occ textures, they have been added to the material file !
-
Yes, I've noticed all the mods and I appreciate them, especially the jets and red lights. They are a killer! :)
Now i have to figure what to change with the legs to have a real flying version :-\
Professionally, the rotule+legs assy should be rigged with a triped skeleton so that the legs could be posed using rotation gizmos. 8)
But since we aren't seeking the easy ways (hehe), we should obviously split the front legs into two distinct meshes. The back leg should be lifted a little in parallel with the fuselage, and the front legs, rotated backwards on both sides of, and parallel to, the back leg. (see the picture below)
I think this will also need some adjustments to the rotule_ext and rotule_lisere meshes.
-
Here is what i came with, for the flying version...
-
Looks cool! :D
-
I couldn't use the .stl pilot, because it is a scanned model, and the mesh quality is too low :-\
-
Don't even try to, because the only pilot that ever flew the Oblivion bubble ship was Tom Cruise in one or another of his clone reincarnations. ;)
Unless we're able to find Tom's textured body or head model let the bubble cockpit remain unmanned.
-
Skytower platform...
-
OMG! :o
This is terrific! Is it just the round platform without the passageway/living cubicle?
Tell you what: I'll send you the shader that renders AO like my ObjReader does, and I would like to try and generate the real AO map for the platform in Blender (when you're done with the model) so that you won't need the pseudo-shadow mesh at all...
-
Is it just the round platform without the passageway/living cubicle?
Yes, just the single platform for the purpose of self centering of the view port.
And then, no more need to have a pilot within the cockpit ;)
-
Awesome!!! 8)
Here's the "new" normalfrag_shader code; use it instead of your current "reference" ObjReader shader in the Mobj_LoadShader() proc:
const char* normfrag_shader =
"#define BUMP_NORMAL 0\n"
"#define BUMP_PARALLAX 1\n"
"#define BUMP_STEEP 2\n"
"#define BUMP_SELFSHADOW 3\n"
"//#define SPEC_INTENSITY_POINT 4.3 // Point light\n"
"//#define SPEC_INTENSITY_DIRECTIONAL 1.5 // Directional light\n"
"//#define SPECULAR_FACTOR 1.75\n"
"//#define SPECULAR_ALPHA 0.1\n"
"//#define SPEC_FACTOR_NO_SPEC_MAP 0.6\n"
"//#define ENV_ALPHA_FACTOR 0.3\n"
"//#define GLOW_MAP_INTENSITY 1.5\n"
"//#define AMBIENT_LIGHT_BOOST 1.0\n"
"uniform sampler2D sBasemap; // colorMap\n"
"uniform sampler2D sNormalmap; // normalMap\n"
"uniform sampler2D sSpecmap; // specularMap\n"
"uniform sampler2D sShadowmap; // shadowMap\n"
"uniform sampler2D sHeightmap; // heightMap\n"
"uniform float materialAlpha;\n"
"uniform int nLights;\n"
"uniform int nLightFlags;\n"
"uniform int nBumpMode;\n"
"uniform vec3 viewDir;\n"
"varying vec4 position;\n"
"varying vec3 lNormal;\n"
"varying mat3 tbnMatrix; // to calc tangents for sNormalmap\n"
"void main() {\n"
"vec2 newUV;\n"
"vec2 texCoord = gl_TexCoord[0].xy;\n"
"vec3 eyeDir = vec3(normalize(-position).xyz); // Camera is at (0,0,0) in ModelView space\n"
"if (nBumpMode == BUMP_STEEP) {\n;"
"vec3 eDir = normalize(eyeDir); \n"
"vec2 vParallaxDirection = normalize(-eyeDir.xy);\n"
"// The length of this vector determines the furthest amount of displacement\n"
"float fLength = length(eDir);\n"
"float fParallaxLength = sqrt(fLength * fLength - eDir.z * eDir.z ) / eDir.z;\n"
"// Compute the actual reverse parallax displacement vector\n"
"vec2 vParallaxOffsetTS = -vParallaxDirection * fParallaxLength;\n"
"// Need to scale the amount of displacement to account for different height ranges\n"
"// in height maps. This is controlled by a designer-editable parameter\n"
"float parallaxScale = 0.3; // can be a uniform\n"
"vParallaxOffsetTS *= parallaxScale;\n"
"float nMinSamples = 6.0;\n"
"float nMaxSamples = 1000.0 * parallaxScale;\n"
"float nNumSamples = mix(nMinSamples, nMaxSamples, 1.0 - eDir.z);\n"
"float fStepSize = 1.0 / nNumSamples;\n"
"float fCurrHeight = 0.0;\n"
"float fPrevHeight = 1.0;\n"
"float fNextHeight = 0.0;\n"
"float nStepIndex = 0.0;\n"
"vec2 vTexOffsetPerStep = fStepSize * vParallaxOffsetTS;\n"
"vec2 vTexCurrentOffset = texCoord;\n"
"float fCurrentBound = 1.0;\n"
"float fParallaxAmount = 0.0;\n"
"while (nStepIndex < nNumSamples && fCurrHeight <= fCurrentBound) {\n"
"vTexCurrentOffset -= vTexOffsetPerStep;\n"
"fPrevHeight = fCurrHeight;\n"
"fCurrHeight = texture2D( sHeightmap, vTexCurrentOffset).r;\n"
"fCurrentBound -= fStepSize;\n"
"nStepIndex += 1.0;\n"
"}\n"
"vec2 pt1 = vec2( fCurrentBound, fCurrHeight );\n"
"vec2 pt2 = vec2( fCurrentBound + fStepSize, fPrevHeight );\n"
"float fDelta2 = pt2.x - pt2.y;\n"
"float fDelta1 = pt1.x - pt1.y;\n"
"float fDenominator = fDelta2 - fDelta1;\n"
"fParallaxAmount = (pt1.x * fDelta2 - pt2.x * fDelta1 ) / fDenominator;\n"
"vec2 vParallaxOffset = vParallaxOffsetTS * (1.0 - fParallaxAmount);\n"
"newUV = texCoord - vParallaxOffset;\n"
"} else if (nBumpMode == BUMP_PARALLAX) {\n"
"float scale = 0.04;\n"
"float bias = -0.025;\n"
"vec3 h = normalize(tbnMatrix * eyeDir);\n"
"float height = texture2D(sHeightmap, texCoord).r;\n"
"height = height * scale + bias;\n"
"newUV = texCoord + (height * vec2(h.x * h.z, h.y * h.z));\n"
"//if (newUV.x > 1.0 || newUV.y > 1.0 || newUV.x < 0.0 || newUV.y < 0.0) discard; // ML: doesn't work for tiled tex coords w/o one more texture scale uniform\n"
"} else {\n// if (nBumpMode == BUMP_NORMAL) {\n"
"newUV = texCoord;\n"
"}\n"
"vec4 lightDiffuse = vec4(0.0, 0.0, 0.0, 1.0);\n"
"vec4 lightAmbient = vec4(0.0, 0.0, 0.0, 1.0);\n"
"vec4 lightSpecular = vec4(0.0, 0.0, 0.0, 1.0);\n"
"vec4 lightAmbientDiffuse = vec4(0.0, 0.0, 0.0, 1.0);\n"
"vec3 normal = texture2D(sNormalmap, newUV.st).rgb * 2.0 - 1.0;\n"
"normal = normalize(tbnMatrix * normal);\n"
"vec3 lightDir;\n"
"lightAmbient = gl_FrontMaterial.emission + (gl_LightModel.ambient * gl_FrontMaterial.ambient);\n"
"int lightFlags = nLightFlags;\n"
"#pragma optionNV unroll all\n"
"for (int i = 0; i < nLights; ++i, lightFlags >>= 1) { // MAX_LIGHTS\n"
"if ((lightFlags & 1) == 0) continue; // ML: inspect individual on/off bitfield flags\n"
"float specularIntensity = 1.0;\n"
"float attenuation = 1.0;\n"
"vec4 lpos = gl_LightSource[i].position; // ML: speed up access\n"
"// Attenuation and light direction\n"
"if (i != 0 && lpos.w == 1.0) {\n"
"// Positional light source\n"
"float dist = distance(lpos.xyz, position.xyz);\n"
"float spotEffect = 1.0;\n"
"attenuation = spotEffect / (gl_LightSource[i].constantAttenuation + (gl_LightSource[i].linearAttenuation * dist) + (gl_LightSource[i].quadraticAttenuation * dist * dist));\n"
"lightDir = normalize(lpos.xyz - position.xyz);\n"
"specularIntensity = 4.3; // Point light, SPEC_INTENSITY_POINT\n"
"} else {\n"
"// Directional light source\n"
"lightDir = normalize(lpos.xyz);\n"
"specularIntensity = 1.5; // Directional light, SPEC_INTENSITY_DIRECTIONAL\n"
"}\n"
"// Ambient and Diffuse\n"
"lightAmbient += (gl_FrontLightProduct[i].ambient * attenuation);\n"
"lightDiffuse += ((gl_FrontLightProduct[i].diffuse * max(dot(normal, lightDir), 0.0)) * attenuation);\n"
"// Specular\n"
"float NdotHV = clamp(dot(normal, normalize(eyeDir + lightDir)), 0.0, 1.0);\n"
"lightSpecular += ((gl_FrontLightProduct[i].specular * pow(max(0.0, NdotHV), gl_FrontMaterial.shininess)) * attenuation) * specularIntensity;\n"
"}\n"
"// Occlusion\n"
"vec3 depth = texture2D(sShadowmap, newUV).rgb;\n"
"lightAmbientDiffuse = lightAmbient + lightDiffuse;\n"
"lightAmbientDiffuse.rgb *= depth;\n" // MLL 09-05-2018: make AO affect diffuse lighting
"//lightAmbientDiffuse.rgb *= texture2D(sLightmap, texCoord2).rgb;\n"
"// Base color\n"
"vec4 baseColor = texture2D(sBasemap, newUV);\n"
"vec4 fragmentColor;\n"
"fragmentColor.rgb = baseColor.rgb * max(lightAmbientDiffuse.rgb /* * 1.0*/, gl_LightModel.ambient.rgb - 0.425); // ML: redundant AMBIENT_LIGHT_BOOST removed\n"
"fragmentColor.a = baseColor.a * materialAlpha; // !!! ML: !!!\n"
"// Spec color\n"
"fragmentColor.rgb += lightSpecular.rgb * (texture2D(sSpecmap, newUV).rgb * depth * 1.75); // SPECULAR_FACTOR\n"
"fragmentColor.a += (dot(lightSpecular.a, lightSpecular.a) * 0.1); // SPECULAR_ALPHA\n"
"gl_FragColor = fragmentColor * 2.0;\n" // MLL 09-05-2018: allow 100% overbrightening
"}";
It has two major fixes:
1. It renders AO in both ambient and diffuse channels; and
2. It allows our current "stray light" control to overbrighten normal-mapped materials in the scene up to 100%. So, the former 100% full-bright is now exactly at the control's mid-position, and drawing the thumb fully upwards now yields genuine +100% overbrightness. I am sick and tired of using illegal 2.0 2.0 2.0's in the color channels whenever I need extra brightness/shininess in our materials.
-
Thank you for the new shader!
However the change you have done for stray light, breaks too much of the existing projects , thus (until we have a new global parameter) i keep the previous "gl_FragColor = fragmentColor;". :-[
I have a few things to fix onto the platform, but i shall post it soon.
-
My friend,
We're definitely moving away from the immediate mode and pure Lambertian and Phong shading towards more modern, capable and versatile composite material shading with rich texture sets. Therefore our normfrag_shader becomes predominant in our rendering pipeline. It is the main tool we should concentrate on, and the other render modes shouldn't prevail over that main tool regardless.
In fact it is very easy to adapt all our existing .MAT files to this new reality. If the .MAT file doesn't have any special lighting specs, just set its #straylight meta parameter to 50 and there you go exactly with its former 100% lighting. If it formerly was 75% then set it to 25 or 30 and there you have its original light intensity again. No other light or material adjustments are necessary.
FFP and normalmap-less Blinn-Phong use other shaders that aren't affected by this quick fix, so that the simplest models (like e.g. the Iron Man model) will be rendered exactly as before in both FFP and PPL modes of operation.
-
Note: for better reality the bubble ship should not be exactly centered to the middle of the platform ::)
LOL had Tom's clone landed his bubble ship so carelessly just one single time, he would've been disqualified and incinerated by the aliens immediately. ;D
-
Here is the release candidate version for both "static" and "flying".
I learned how to create ambient occlusion materials with c4d, and this release candidate version is using several revisited meshes to better match the movie original (especially around the rotor tail section, and the static platform).
-
Oh Patrice,
The model looks simply exquisite... I bet here we got by far the best bubble ship on the market! :D
And it was real fun to work on this model. Thank you again for the great job you've done!
(The bluish haze we're currently trying to emulate with lighting is in fact a post-processing effect. When working with my earlier immediate mode engines, I used to simply render a final semi-transparent viewport-sized tinted quad to produce the exact same effect. If we run any Oblivion movie screenshot through the Auto levels filter in Photoshop, Gimp or Paint.NET, we will get that bluish tint removed and we'll see the scene as it used to look under the original movie studio lighting. ;) )
-
The color of the original model under studio lighting is almost white, with very few surface artefacts, on the platform the white color turns to light blue due to sky reflection, see the attachment.
Indeed the main_body surface, and both bubble engines should be more glossy.
-
Auto levels in Paint.NET: studio lighting, true colors, no more light-bluish post-processing tint. Streaks of dried dirt seen vividly all over the left and right engines, winglets, fuel tanks, back leg, and gun turret. Just like they would be on any existing combat aircraft. ;)
-
Our model should match the movie tint, Tom Cruise himself looks like a bluish smurf.
That is the way the whole movie has been rendered, and we are in a fictitious earth, after a major nuclear conflict that put a lot of dust in the air, changing the light color for ever, except in the idyllic refuge area where one of the clone is listening old good vinyls :D
-
I am reworking the drone model to add a little fellow to the flying version…
-
I'm looking forward to seeing the result. :)
-
First look…
The use of AO makes a huge difference !!!
-
It looks very good indeed! :)
From what I can see, there's not only AO but also that crop_ks specular map used?
-
Here is my first WIP of Drone166, feel free to enhance some of the textures, because this is my first shot. 8)
I have totaly reworked the model ???
-
Patrice,
Your work is very impressive. 8)
I don't think I can really improve on what you've done.
I have just one request.
Look very attentively through the controls that affect your AO baking. There must be some selector or input box or whatever that controls the width of grayscale margins that should surround each occluded fragment in the AO texture atlas. (see engine_axe_occ.png below with 6 px wide margins around each fragment of the engine axle mesh)
These margins should be approx. 5 to 15 pixels wide depending on how precise the mesh's UV mapping actually is. The margins help to disguise the abrupt, jagged borders of AO texture areas at places where the occluded fragments overlap. The jaggies generate ugly texture seams similar to those seen in Bad_AO_Texture_Seams.png below.
Blender has its AO margin width set to 16 pxs on default. Your AO maps have either a 1 px wide margin or no margins at all. :-\
-
Mike
The main difference between C4D and Blender, is the default background color used in the AO texture.
Blender uses white, C4D's black.
However the Blender GUI is so much complex compared to C4D, indeed i couldn't figure how to use it :-[
I have also a pixel tolerence in C4D, however that's not enough, the only way to solve the issue is to rework the texture with PSD using the layer outline with white color, to antialias the border section.
This is what i am doing now...
-
My Blender AO shadows seem sharper and cruder than yours and that's why I didn't present my own versions at once.
Here's a nice tutorial on AO baking in Blender. (https://www.youtube.com/watch?v=1IV5wK2e4I8)
The voice is irritating but the tips and tricks to make the shadows smooth and precise are cool. In the AO bake section of UV map editor, make sure to tick the Normalize checkbox; Blender will normalize the map shades against the white level, and the AO map background will also turn to pure white. Don't forget to adjust the margin width to some 5 pixels.
In a multi-mesh model, just select the desired mesh whose AO you're going to bake in the current iteration, in the mesh tree pane of the UV map editor.
-
Here is my AO (PSD) reworked copy, is it any better ???
-
Alas my friend,
Those maps seem to be a little better at some places but the others are still not good enough... ???
And certainly the Photoshop tool chain is far more laborious. We are going to be much better off and safer with Blender and its AO margin/normalization/number-of-samples options if C4D doesn't have their direct equivalents. And we'll be more professional, so to speak. The safety margins make the AO map background color issue totally irrelevant to the final look of the model.
The tuto I pointed you to contains all the know-how to generate efficient high-quality AO maps in Blender real fast. It will also make our tool chains closer so that we'll get more competitive in case something in the model needs a quick fix or two.
-
Thank you for the feedback.
Here is another copy with better antialias.
-
OK Patrice,
Here's a full set of Blender AO maps alongside your set of C4D AO maps.
The Blender maps have been generated fully automatically without my intervention with 20 ray tracing samples, 5 px margins and normalized to the white level. They look much much smoother and uniform throughout the entire model.
However they don't eliminate the jaggies completely. As it happens, the jaggies are due to how Blender/C4D ensure the transition from lit to hidden (fully occluded) areas, which appears too abrupt. (see the picture below)
Sadly the transition gradient cannot be controlled in Blender, and I suppose neither can it be adjusted in C4D. :'( Of course, the UV's of respective offending border polies could be corrected manually after the AO maps have been baked but it would require much manual effort. Probably the transition borders could still be smoothed out to gradients by blurring the entire map in Photoshop? :-\
On the brighter side of things, the C4D and Blender maps seem to be generally compatible.
-
More on AO Jaggies
It isn't Blender/C4D AO algo alone that's responsible for the jaggies. The current uber-shader is also taking its toll.
The shader original code used the AO map in its ambient channel only, which led to the shadows being almost never visible. Not only is ambient lighting rarely used in our models at all even at its weakest settings, but it also is generally the weakest, the least noticeable lighting component in the final color intensity of the screen pixel even at its maximum 1.0 setting. Thus roughly, the screen pixel final color used to be
Pixfinal = (Colamb * MapAO) + (Coldiff * Mapdiff)
In other words, the AO map did not affect the diffuse component (the strongest one) at all and we wouldn't see the AO map jaggies (nor the AO shadows, for that matter) when Coldiff happened to be bright, and Colamb*MapAO, pitch-dark for whatever reason.
I thought it wasn't correct either logically or visually. We do see object shadows in the real world when there is no ambient lighting around (no surrounding scenery for the light to scatter by and/or reflect from) and there is only the very distant sun shining down upon the object, which is what the directional diffuse lighting component is supposed to emulate.
So I changed the shader code roughly in the following way:
Pixfinal = (Colamb * MapAO) + ((Coldiff * Mapdiff) * MapAO)
so now we're seeing beautiful shadows under any amount of the always-present diffuse lighting, and these shadows fade out smoothly and gently as we're dimming out the scene lighting with our "stray light" fader.
I think we should stick to this lighting scheme further on. Which also means we should find a technique practical enough to mask off, minimize or eliminate completely the jaggies we're seeing now in some extreme cases like this drone 166 model hull meshes.
What is your opinion about all this, Patrice? ???
-
First let me say thank you for your efforts.
BTW it helped me to detect wrong meshes holes that i didn't see until now.
My eyes are not so much accurate that they used to be… :'(
I shall fix the gap hole first of all, then i will change the color shader to follow your suggestion, and once done i will give you my feedback.
-
My eyes are not so much accurate that they used to be… :'(
Your eyes are almost perfect, my friend. I think your eyesight is going to be your last sense to fail. :)
But no, you don't have to change anything in the shader proper. The one you have now in your sources has all my mods already implemented. I just described to you what I did in the past and why I did it. Regretfully my mods also (partially) caused those jaggies to be seen in the drone model, or at least promoted their visibility. But I still consider this as a very special case seldom observed in the majority of other models, and thus I vote for keeping the shader behavior as it currently is in our "reference" ObjReader code.
-
Regretfully my mods also (partially) caused those jaggies to be seen in the drone model, or at least promoted their visibility.
I can live with it, as long as i am able to clear the most obvious jaggies with the help of PSD.
-
That is my last and final attempt for that model. :-X
-
I've tried different modes to blend AO with the diffuse channel in the shader instead of our current multiply blending. All of them are either visually unfit for the purpose or make the jaggies visible at critical places. There's only one method I know of to suppress them reliably whenever necessary, which is to motion blur the offending regions selectively in Photoshop or alike.
I think we can't refuse to use the AO maps in our models or restrict their usage to the ambient channel only.
-
There's only one method I know of to suppress them reliably whenever necessary, which is to motion blur the offending regions selectively in Photoshop or alike
Yes, this is what i did, and i can live with it, because the resulting quality is worth the extra work.
-
And finally, here is the mixed version…
Bubble ship is flying under control of drone 166 until there is a pilot on board. :)
-
The picture looks very cool! 8)
My comments will follow tomorrow night when I'm back home from Lithuania. :)
-
I keep trying to put a pilot inside of the cockpit ;)
-
:D
Seriously, I think both the pilot's seat backs and the pilot should be made perhaps 20% taller.
This pilot will not be able to reach the switchboard above his head.
-
Ok, now he should be able to reach the switchboard. 8)
-
Yyyesssss! :D
-
Here is the pilot for the flying version, that was a tedious work, and even if not perfect i think the result is much better than an empty cockpit.
And i think it is the only one mixing the drone + the flying Bubble ship (even without Tom)
Everything is running at 75 FPS by me (that was a true challenge to keep this model to only 6238962 indices !!!)
-
Patrice,
In your WIP model's drone, please delete the mesh called gun_domes_dark. Its horizontal planes have improper UV's and consequently, improper AO mapping. Delete the existing gun_domes_dark_AO.png texture that the mesh uses.
Substitute the deleted mesh with the one that's zipped below and has its UV's fixed, and use it with the AO map that comes in the zip. The map also fixes a few ugly AO seams.
More fixed AO textures will come in due time.
-
Yes Patrice,
The model looks very rich and very original. :)
(Please do what I asked above and resend me the .OBJ file)
P.S. I have 15FPS only. ???
On the brighter side, I have collected the sum I need for a new GTX 1060 Ti with 6GB VRAM. Will buy one next week. :)
-
Yesss, thanks a lot! :)
I'll be adding a few more fixed AO maps when I have them all ready.
Thank you for the great work you've done, my friend. The model looks really cool, and it was fun to see its progress. :)
-
On the brighter side, I have collected the sum I need for a new GTX 1060 Ti with 6GB VRAM. Will buy one next week.
Great !!!
-
OK Patrice,
Overwrite a few of your AO maps with the ones from the zip, and the drone will now look almost as perfect as the bubble ship. 8)
But it was one heck of a f**k indeed to do all this via manual motion blur and grayscale noise... >:(
-
Thank you, the drone junctions are almost perfect now !
I am thinking of posting the 2 versions: static and flying.
I plan to try AO on the static version to emulate a true ground shadow...
-
It's my pleasure to be of help. :)
I am thinking of posting the 2 versions: static and flying.
By all means, Patrice. Both models deserve their own place in the collection.
I plan to try AO on the static version to emulate a true ground shadow...
I'm afraid you aren't going to succeed. AO (and its approximate calc) applies to closely spaced surfaces like e.g. room wall corners, or vents, or ducts. The bubble ship's hull is too far away from the ground to visibly shadow it under the parallel directional lighting used to bake the AO maps. You'll need one or more nearby point or spot lights added to the scene to cast sharp enough shadows on the ground. (that's how light maps are baked)
So far your artificial "shadow" mesh looks like the best approximation of veritable penumbra shadow cast on the ground.
-
Here is what i got, and it looks rather good to me…
Ka 0.0754310002326965 0.0754310002326965 0.0754310002326965
Kd 0.75 0.75 0.75
Ks 0.15 0.15 0.15
map_Kd mb.png
map_bump neutral_bump.png
map_Ka plate_AO.png
Ns 225
illum 2
Note: I am merging the cockpit of the flying version into the static's.
-
Hehe no,
This AO map doesn't fit into my copies of your static bubble ship. You've probably got some later WIP version of that model.
OK I'll wait till you publish the models in the Collection. :)
-
(My brand new 6GB VRAM nVidia GTX 1060Ti has just arrived. Will install tomorrow.)
8)
-
Actually, you don't need the shadow.png map in the static bubble ship zip any more. ;)
-
Ok, i have released the Static version using the new cockpit, the new shadow effect, and new lighting to match the clouds.png wallpaper, and a few more AO textures.
Let's see the FPS you will get with your new GTX. ;)
-
Actually, you don't need the shadow.png map in the static bubble ship zip any more.
Indeed it is still there, but very subtile 8)
-
In fact, my existing GTX 650Ti's static bubble ship FPS is exactly 60. :P
It is the flying version with its drone and pilot that seems to have a problematic FPS rate of 15, presumably due to its 2GB VRAM limit. The card seems to be swapping some of its loaded textures into the conventional RAM. :-\
-
It is the flying version with its drone and pilot that seems to have a problematic FPS rate of 15, presumably due to its 2GB VRAM limit. The card seems to be swapping some of its loaded textures into the conventional RAM.
The official flying version has been released, tell me the FPS you got with your new GTX 1060.
-
You won't believe it but it's 60FPS (my current exact monitor rate) even in the full screen mode (can't capture it with the FPS counters on) at approx. 40% GPU load. :D
Top left -- ObjReader's FPS counter, bottom right -- Fraps. 8)
-
Congratulation, you must be very happy!
I have attached a screen shot of mine, running the OR process alone...
-
Patrice,
I've got 92 processes = 1425 threads running concurrently with ObjReader. I run a hellofalot of desktop gadgets (ca. 5% CPU power) and a few semi-transparent sliding dockbars (another 4% CPU power) for my tools and apps. ObjReader proper was consuming only 5.1% CPU the moment I took the topmost screenshot below. Regarding GPU consumption, we're on a par with each other when the animated bubble ship is made to rotate at its default zoom on scene load. :D
And ObjReader proper was consuming around 26% CPU when I took the bottommost full-screen shot with the model zoomed in decently to occupy the entire unobscured viewport. :)
It's like heaven and hell compared to my former GTX 650Ti readings, which in their turn were not so bad at all compared to cheaper office-style video cards. And my GPU's temperature at full screen is now ca. 38oC only at 30% fan speed. (not a sound in the room whatsoever! 8) )