Special Aircraft Service
The SAS Factory - Tech Help, Ancient Mods etc. => Tech Help (other than BAT or IL-2 Great Battles) => Tech Help : Making Mods => Topic started by: karla on February 27, 2015, 04:05:37 PM
-
I've almost completed CVA-31 but I am perturbed by uneven shading, or differences in lighting, on the carrier flight deck. It can be seen in reply #67 of https://www.sas1946.com/main/index.php/topic,42027.50.html. The stern third of the deck is obviously darker than the rest of the flight deck. One can also see other differences in shading around the ship which are certainly not caused by differences in the texture maps. The uneven shading is always at the boundaries or edges of the various objects in the 3D model.
Is it because of my graphics card or what?
Ubuntu 14.04 64 bit/ Wine 1.7.34
IL2 1946 4.12.2m with High Resolution/True Color Textures Mod by carsmaster and SA~Storebror
NVIDIA GT240
-
I don't know about the graphics card or 3D model part of it karla but,uneven shading or the stern third of the deck being obviously darker would be a good thing I think.Planes landing causing tire marks on top of that planes staging there before flight ops leaking hydraulic fluid+oil and tons of foot traffic would obviously make the stern darker. (http://i57.tinypic.com/2ynrvyf.jpg) (http://i62.tinypic.com/v7zdif.jpg) Tons of uneven shading. :-X
-
Thanks for the reply Gumpy.
I don't think you appreciate the level of detail in my model, there are 15 layers of texture in Gimp to create just the map for the flight deck surface - tyres and oil being two of them.
My problem is the rendering in game due to the graphics card setting, the HD mod, interference between sub-models or something else. Because I know the texture maps are as good as I can make them I will have to release CVA-31 as it is.
-
Check your normals are facing the right direction.
I have seen this many times on HIM files, even stock ones.
If not check the material properties in game, especially the ambient and diffuse settings.
-
Thanks Stainless. I've been working on the model for 7 months now and still spot the odd normal that's in the wrong direction. It's easy to see in Blender 2.49b - the face becomes transparent. So, the problem with the huge flight deck areas is not because of normals. The materials in question are shared across a number of faces and objects and vary in their rendering in game; the Blender 3D model looks perfect. Puzzling. However, I can just about accept these variations and guess that not many others will bother much and I will therefore release the model as is - but I'll carry out a post mortem and study my archives to see when the problem first arose.
Thanks anyway.
-
Hi, karla,
Have you checked smoothing groups? I haven't used Blendy exporter (nor Blender since a loooong time) but with Buggy it used to export everything with just one smoothing group so the shading around the whole object once exported in game looks odd.
May it be that the Blendy exporter has some issues with smoothing groups, I doubt it, but just in case...
My bet is that maybe you need to make use of "null" material to make the separated parts of deck (or hull if it's the case) look smooth once exported. I'm not familiar with shipbuilding at all, but this odd shading looks like this kind of issue. There is a tutorial by Loku
https://www.sas1946.com/main/index.php/topic,2707.0.html (https://www.sas1946.com/main/index.php/topic,2707.0.html)
explaining how to setup null material and what to do next. Basically you need to have attached to the main hull parts some extra faces that will be deleted after export the mesh object. This will keep the smoothing without breaking it along the borders of separated meshes that should look as one continuous surface.
-
There is something similar on Colossus class model too, but on hull... Is there an easy fix for it?
(http://i1296.photobucket.com/albums/ag19/milemiletich/2015-03-02%20at%2020-23-17_zpso6rcdykd.jpg) (http://s1296.photobucket.com/user/milemiletich/media/2015-03-02%20at%2020-23-17_zpso6rcdykd.jpg.html)
-
Hi, Boyan,
I can't tell if this is really the case, as I may be completely wrong, I really don't know what the modelling requeriments are for ships, it's just the impression I've got looking at the pictures.
Textures usually hide or mask smoothing or uneven shading issues, that's the reason I use a simple texture as a skin filled with just one medium-light colour to help me when checking these kind of issues.
If the lack of null material is the reason for the uneven shading, a bit of work is needed from the modeller to re-export the parts after adding some extra faces and fiddle a little deleting a bunch of geomtry and texture vertices in the .msh text files.
-
Thanks for areas to start looking Stainless and just-champi. I can see the same problem on the Colossus, Boyan: one third from stern is a modelling joint and possibly a crooked one at the bow third. I was unable to discover when the problem first arose and, unfortunately, I haven't the time this month to carry out any tests.
I came across "non conformant texture clamping" which may be the culprit. Apparently, in older games seams at the edges of textures are visible in GL and Nvidia has a fix for it. However it didn't work with my setup. It may only be a problem with OpenGL (I should have said I'm using OpenGL) and not with DirectX, so, I'll leave it for now. If I find a fix for it I will post here.
Thanks anyway.
-
Why don't you try loading it in my modtool and see what it looks like.
It's just a different renderer and although I can't say it matches the in game renderer, it map give you some clues.
-
Thanks Stainless. I was unable to get your modtool to run under Linux/Wine at first attempt. I've tested out a few more suspect parameters including my NVidia settings.
I'm using carsmaster's and storebror's HD mod and used their "Lite" version with no effect. I've also varied settings in my CVA-31 .mat files with little or no effect - except specular and specularpow. They had a significant effect on the appearance but didn't eliminate it.
It looks like a rendering engine problem and I intend to test it out sometime soon (if possible, with Stainless' modtool or even in a locally built Windows environment (I'm running Ubuntu)).
Its a minor problem which will get solved someday ......
-
One thing I have noticed on carrier decks is you can get issues with precision in the depth buffer.
I would try playing around with the "tfShouldSort" flag in the materials and see what happens.
-
This thread is not dead ...... yet
@Stainless, thanks. I should have replied earlier, but I tried "tfShouldSort" flag from 0 to 1 which, other than giving no shadows, gave no other effect. I also tried "tfnowritez" from 0 to, 1 for fun, which gave semi transparent effects. I guess I reluctantly will have to set up a PC with Windows and DirectX and IL-2 to really test out the problem. However, I'm still trying to get to the bottom of this uneven rendering problem by other means.
I have found that it is essentially the effects of lighting on the faces of a mesh: if the mesh face is large - like the flightdeck of a carrier - the boundaries are easier to see. It is also directional - so it is the rendering and not a defect in the mesh model.
Using my CVA-31 development model as an example, the flight deck is composed of three major parts. If the sun is lighting the deck longitudinally then the the two boundaries can be easily seen between the three deck parts because of the separate gradations in the shading of the three parts. If the sun is lighting the deck from the side then the three parts are seen as a whole - except that three sides nearest the sun are uniformly lighter than the three sides away from the sun. In other words, the lighting (or shading) is exaggerated.
One idea was to change the HD Mod DLLs (carsmaster + storebror) to 'lite' = no effect.
I've also tried changes of the usual suspects in the conf.ini file: texqual, texflags.usealpha, texflags.disableapiexts, arbmultitexturext, usepalettextension, hardware shaders, diffuse light, shadows, videosetupid, visibility distance, texlarge, effects, forceshaders1x = not the effects I wanted.
Hmmm ....
-
The main suspect now seems to be the .mat file. I found a thread about 'sunglasses' in IL2 and used variants of one of the .mat files. There were two or three significant effects - one of them exaggerated the uneven shading. So, various settings in .mat [Layer0] were tried with little success. These included: tfshouldsort, tftesta, tftestz, tfnowritez, tfmipmap, tfblend, tfcompressmajoralpha, tfnocompress16bit. tfnocompressarb, tfupdateclear. This led on to the .mat [LightParams] settings and it was found that if the diffuse setting is reduced, ambient turned up slightly and no shine nor specular, then the defect is reduced quite a lot. Maybe it's a combination of two parameters - which would take too long a time to investigate.
The defective or uneven shading or rendering is still there but it is not so obvious. I'll keep looking for inspiration, or maybe someone will come across this thread and know about the problem.
-
Tried Diffuse and Ambient on Colossus class ship. Stock values are 1.0 for both. The only way the uneven shading is removed is when Diffuse is set to 0, but then the ship look as if there is no lighting at all...
(http://i1296.photobucket.com/albums/ag19/milemiletich/2015-05-07%20at%2012-08-04_zpsg9k7wfc7.jpg) (http://s1296.photobucket.com/user/milemiletich/media/2015-05-07%20at%2012-08-04_zpsg9k7wfc7.jpg.html)
(http://i1296.photobucket.com/albums/ag19/milemiletich/2015-05-07%20at%2012-11-35_zps1z7628sb.jpg) (http://s1296.photobucket.com/user/milemiletich/media/2015-05-07%20at%2012-11-35_zps1z7628sb.jpg.html)
-
Then to me, I'm back to the lighting calculation.
You can see a clear line where the three sections of the hull join.
The stern look to me like the light is towards the front of the ship, the middle section looks like the light is towards the camera, the bow is just screwed. Maybe forward and up 45 degrees.
If you are 100% sure the normals are correct, then I would try two things.
1) render a screen shot with a pure white texture and ambient and specular set to 0, so all you are seeing is the diffuse lighting.
2) look at the attaching matrix for each part of the ship. See if you have anything other than a translation in it.
The reason I ask about the attaching matrix is the way lighting works.
You have a normal attached to a vert, this starts out in the same coordinate system as the mesh.
In the game this is transformed by the world matrix.
For HIM meshes this is the accumulated attaching matrix.
The angle is then calculated between the light source and the transformed normal, and this is used to work out the diffuse lighting term.
So in your 3D editor the normals may look perfect, but in the conversion process something gets screwed.
I know the normals on a lot of stock Il2 meshes are wrong, but since they work in game, something is screwed up in the IL2 renderer.
Without source code I cannot figure out what the bug is, I can only give you things to try out to gather evidence.
If I can figure out what IL2 is doing wrong, I can make suggestions on ways to do bad things to your mesh that make it look good.
-
(https://www.mediafire.com/convkey/ad3d/pub0reqcx4xx3uu6g.jpg)
.tga white texture maps; .mat files amb=0 spec=0 diff=1
@stainless - there's something obviously wrong: the forward hull is white and the centre hull is black; the liferafts have uneven local lighting and the uneven lighting on the deck exposes all the mesh faces.
A quick check of hull1 and hull2 .msh files shows no obvious differences. As you know, the structure of the .msh file is -
[Common]
NumBones 0
FramesType Single
NumFrames 1
[FaceGroups]
3253 2249
0 0 3253 0 2249
[Vertices_Frame0]
[MaterialMapping]
[Faces]
[ShVertices_Frame0]
[ShFaces]
[LOD1_Materials]
[LOD1_FaceGroups]
[LOD1_Vertices_Frame0]
[LOD1_MaterialMapping]
[LOD1_Faces]
and so on
The only area I can see where things go wrong is .msh [FaceGroups]. They all seem OK to me in hull1 and hull2 for example (total number of vertices and faces adding up correctly).
So stainless, can you tell me what an 'attaching matrix' is then I can start an investigation?
Many Thanks
-
The attaching matrix is defined in the HIM file, look at this example
[_ROOT_]
VisibilitySphere 78.89842
CollisionObject sphere 85.89842 0.0 0.0 0.0
[Hull1]
Mesh Hull1
Parent _ROOT_
Attaching 0 1.2 0 -1.2 0 0 0 0 1 63.3034 0.0299933 2.29914
CollisionObject c1a
CollisionObject c2a
CollisionObject c3a
CollisionObject c4a
CollisionObject c5a
CollisionObject c6a
CollisionObject c7a
[Hull1_dmg]
Mesh Hull1_dmg
Parent _ROOT_
Hidden
Attaching 0 1.2 0 -1.2 0 0 0 0 1 63.3034 0.0299933 2.29914
CollisionObject c1b
CollisionObject c2b
CollisionObject c3b
CollisionObject c4b
CollisionObject c5b
CollisionObject c6b
CollisionObject c7b
[Hull2]
Mesh Hull2
Parent _ROOT_
Attaching 0 1.2 0 -1.2 0 0 0 0 1 -4.22264 0.0300011 2.26734
CollisionObject c8a
CollisionObject c9a
CollisionObject c10a
CollisionObject c11a
CollisionObject c12a
CollisionObject c13a
CollisionObject c14a
The attaching line forms a 3 by 4 matrix
0 1.2 0
-1.2 0 0
0 0 1
63.3034 0.0299933 2.29914
The last line is the translation, so this mesh is at x = 63.3034 , y = 0.0299933, z = 2.29914 relative to the root bone.
The rest is contains the rotation and scaling. An un-rotated, un-scaled mesh would have a matrix like this.
1 0 0
0 1 0
0 0 1
A scaled mesh would have a matrix like this
2 0 0
0 2 0
0 0 2
From this example you can see that if is rotated in the XY plane and scaled by a factor of 1.2 in the same plane . Basically the matrix represents the equation
x = (x*0) + (y*1.2) +(z*0)
y = (x*-1.2) + (y+8) + (z*0)
z = (x*0) + (y*0) + (z*1)
x = 1.2 * y;
y = -1.2 * x;
z = z;
My theory is that either IL2 doesn't rotate the normals correctly, or it calculates it's own normals from the vertex data.
If it calculates it's own normals, then the vertex order is important. A triangle is defined by three points P1,P2,P3. The normal calculated from P1,P2,P3 is totally in the opposite direction from the normal calculated from P3,P2,P1.
This is called the "winding order" and is used a lot in graphics code. You can even cull triangles based on winding order. Graphics engines have commands for it. https://www.opengl.org/wiki/Face_Culling (https://www.opengl.org/wiki/Face_Culling)
If that is the case you need to look for a tool that can manipulate your mesh for you, swapping the winding order and comparing the results with what you have now. Not trivial.
The second possibility is that IL2 does not rotate the normals contained in the mesh correctly. This is harder to prove. I would go through the mesh and replace every normal with a fixed value. Say 0,1,0
If Il2 does not rotate the normals, the lighting will be consistent across the entire mesh, if the lighting varies by mesh part, then the normals are being rotated.
Then it becomes more complex, it becomes guess work. We can definitely see that the normals are not being handled correctly, but what have they done?
I would have to write some code to test out a few ideas. My first guess would be to multiply all the normals by the inverse of the attaching matrix, but it's a guess.
Let me know what you are capable of doing and I'll see if I can help out with the rest.
-
Just had a though, (yes it did hurt before you ask ;D )
The easiest part of the ship to evaluate is the deck. Obviously it should be well lit as it is facing straight up. So change the first part of the attaching matrix to ...
1 0 0 0 1 0 0 0 1
This will remove all rotations from the mesh part. So the deck will be in the wrong place. However if I am correct, the top of the deck will be correctly lit.
If that is the case, then I can fix it. I can add a command to my mod tool which will pre-rotate all the normals by the attaching matrix.
-
Hey, thanks stainless. I'll try changing the attaching matrix for the three decks soon (RL).
I've also had a thought (it took me all night): I wonder if the export from Blender is doing it? My previous carriers were created in Blender on my main Linux PC, exported to GMax on my secondary Windows PC, exported from GMax, grabbed by Yagg, then copied and pasted into the respective .msh files on my main machine. These carriers had no problems, so maybe BlendyBlendy exporter (all done on my Linux machine) may be the culprit. So, I'll also try exporting three decks from GMax in a couple of days and we'll see what happens.
-
It looked good at first: three decks with rotations removed from the matrix and the deck in the wrong place - but I sailed the ship in another direction under the sun and the uneven shading was still there. It is a lighting defect and is more apparent when the source of light is in a particular direction. I'd also come on this option from a different direction by converting the data with exponentials into zeros (if they were tending to zero of course).
However - I think it's fixed - it's the .msh exporter. Three decks processed thro' GMax were perfect. The orientations were incorrect and I haven't yet worked out how to get the right Hier.him data using this process. (My usual method is by exporting via BlendyBlendy exporter which does Hier.him, shadows, LODs and the lot). Unfortunately it seems as tho' BlendyBlendy is bugged. I will now probably export the final version of my model using GMax, BuggyBuggy and Yagg. I will finalise the process by manually copying data into the .msh files - it's really quite tedious.
If you have any suggestions, stainless, I'd rather fix the defective exports from BlendyBlendy than go thro' the laborious process of transferring data and setting up my other PC, using GMax and BuggyBuggy and copying huge quantities of data into .msh files.
Many thanks.
-
Can you post some data for me to look at somewhere?
Mainly I would like to see the msh file for one that came from BlendyBlendy (who came up with that name ? ???) and the same msh exported from BuggyBuggy (which is just as badly named :\'( )
Maybe I can work out a fix from that
-
Hello again Stainless. I exported data of the relatively simple front flight deck directly from Blender under Linux, where I have spent the past nine months creating the carrier. First export was direct from a .blend file to a .msh file using BlendyBlendy exporter (which also exported LODs, shadows, collisions etc which I removed from the test file for simplicity). At the same time I also exported the front flight deck from the same .blend file to a .3ds file. Neither of these export operations had parameters, so there was nothing to change orientation or scales or whatever. The .3ds file was transferred to my Windows PC running GMax then exported from GMax using BuggyBuggy IL2 exporter, then the data was grabbed by Yagg and pasted as a .msh file.
The first two pages of the .msh files are given below. There are differences in LOD headings and materials names which may be ignored. There are, however, differences in the headers for the [FaceGroups] data - which will probably give you a clue.
Blender
//Created in Blender 2.49b, exported using BlendyBlendy bbexporter.py (The_WOZ)
[Common]
NumBones 0
FramesType Single
NumFrames 1
[LOD]
1000
7000
13000
19000
[Materials]
deckL4096
[FaceGroups]
485 272
0 0 485 0 272
[Vertices_Frame0]
-12.4747 77.7903 14.7534 -0.707083 0 -0.707083
-12.4747 77.7903 15.7705 -1 0 0
-12.4747 96.9581 15.7705 -0.999786 0.0183111 0.00714133
-12.4747 74.8329 14.7534 -0.707083 0 -0.707083
-12.4747 74.8329 15.7705 -1 0 0
-12.4747 62.3381 14.7534 -0.894406 0 -0.447188
-12.4747 62.3381 15.7705 -1 0 0
17.2757 77.8144 14.7534 0.707083 0 -0.707083
17.2757 77.8144 15.7705 1 0 0
17.2757 74.8329 15.7705 1 0 0
17.2757 74.8329 14.7534 0.707083 0 -0.707083
17.2757 62.3381 15.7705 1 0 0
17.2757 62.3381 14.7534 0.447188 0 -0.894406
17.2757 62.3381 16.5161 0.707083 0 0.707083
-12.4747 74.8329 16.5161 -0.707083 0 0.707083
-12.4747 96.9581 16.5161 -0.706992 0.00878933 0.707144
-3.5298 132.484 14.8691 0.816492 0.408246 -0.408246
-3.5298 132.484 15.2321 0.349345 0.734458 0.581774
-3.5298 126.852 16.5163 0.707236 0.157262 0.68923
11.7036 132.484 14.8691 -0.414686 0.90994 -0.00387585
13.7036 132.484 15.2321 0.380963 0.846675 0.371441
13.7036 132.484 14.8691 0.876766 0.48088 -0.00204474
-3.48481 128.286 14.9112 0 0.000824 0.999969
11.6779 128.259 14.9112 0 0.000854518 0.999969
11.6779 130.13 14.9096 0 0.000824 0.999969
-11.3542 130.197 14.7154 -0.0383312 0.113132 0.992828
-11.357 127.747 15.7705 -0.518906 0.539048 0.663411
-5.54986 130.149 14.7157 -0.00234993 0.406873 0.91348
17.3856 125.222 16.0307 0.467147 -0.00744652 0.884121
19.309 125.211 14.9894 0.219855 -0.00845363 0.975463
19.3864 127.045 14.9889 0.467147 -0.00744652 0.884121
11.7497 134.43 14.6799 0.0200201 0.138554 0.990143
9.97061 134.451 14.682 0.00228889 0.0934172 0.995605
9.9336 130.091 15.0913 -0.0853298 0.09888 0.991424
11.744 132.564 15.2645 0.000244148 0.299173 0.954161
13.7628 132.564 15.2645 0 0.299417 0.9541
13.7585 134.427 14.6798 -0.00369274 0.155919 0.987732
-3.49252 134.382 14.6725 -0.0343028 0.0673544 0.997131
-3.50791 130.21 14.9538 -0.0625019 0.0800195 0.994812
-1.61148 134.396 14.7363 -0.0625019 0.0800195 0.994812
-11.357 128.222 14.7534 -0.427229 0.830592 0.357158
17.4945 128.222 14.7534 0.897061 0.401837 0.183752
17.2757 96.9581 14.7534 0.707083 -0.001648 -0.707083
17.2757 74.8329 16.5161 0.707083 0 0.707083
17.2757 77.8144 16.5161 0.707083 0 0.707083
-12.4747 77.7903 16.5161 -0.707083 0 0.707083
17.2757 96.9581 16.5161 0.70809 -0.00338755 0.706076
17.4945 126.864 16.5161 0.333415 0.427808 0.840114
-11.357 126.864 16.5161 -0.567614 0.204199 0.79754
-3.50465 130.237 14.9096 0 0.000793481 0.999969
-5.62012 127.729 15.8291 -0.00796533 0.418134 0.908322
13.7224 130.128 14.6843 -0.00750755 0.123508 0.992309
13.7224 128.258 14.9171 0.0180364 0.0736106 0.997101
17.5149 130.181 14.7065 -0.0264595 0.290841 0.956389
11.6839 130.107 14.9554 0.076693 0.0622272 0.995086
-5.5298 132.484 15.2321 -0.365062 0.332224 0.869655
-3.50888 132.564 15.2645 -0.0273446 0.305673 0.95172
-3.50888 134.428 14.6658 -0.0143742 0.293405 0.95587
-1.57388 130.212 15.1305 0.10947 0.0969573 0.989227
-12.4749 84.4438 16.0641 0.408246 -0.816492 0.408246
-13.2363 84.4438 16.0641 -0.666646 -0.333323 0.666646
-13.2363 84.4438 15.5436 -0.408246 -0.816492 -0.408246
17.2332 91.5809 16.0993 -0.408246 0.816492 0.408246
17.9946 91.5809 16.0993 0.666646 0.333323 0.666646
17.9946 91.5809 15.5789 0.408246 0.816492 -0.408246
-12.4747 96.9581 14.7534 -0.708792 0.0169988 -0.705191
-5.5298 126.86 14.8691 -0.894406 0 -0.447188
-5.5298 132.484 14.8691 -0.416639 0.909024 -0.00711081
-3.5298 126.852 14.8691 0.447188 0 -0.894406
11.7036 126.86 14.8691 -0.894406 0 -0.447188
11.7036 126.86 16.5163 -0.706778 0.157476 0.689657
11.7036 132.484 15.2321 -0.635792 0.459517 0.620136
-3.48481 127.793 15.8151 0.00469985 0.333384 0.942778
11.6779 127.766 15.712 0.00698874 0.320048 0.947356
11.6779 130.099 14.9238 0.00469985 0.333384 0.942778
18.1312 127.638 14.5469 0.408216 -0.816492 0.408246
GMax
//Export from: GMax BuggyBuggy Exporter V2.5 by Fatduck
[Common]
NumBones 0
FramesType Single
NumFrames 1
[LOD]
500
[Materials]
Mtl #4
[FaceGroups]
679 272
0 0 679 0 272 0
[Vertices_Frame0]
87.5465 15.0648 14.7592 4.13996e-007 1.0 0.0
87.5465 15.0648 15.7763 4.71732e-007 1.0 0.0
106.714 15.0648 15.7763 0.0183175 0.999807 0.00715624
84.5891 15.0648 14.7592 5.31728e-007 1.0 0.0
84.5891 15.0648 15.7763 4.75121e-007 1.0 0.0
72.0943 15.0648 14.7592 3.05303e-007 1.0 0.0
72.0943 15.0648 15.7763 3.05303e-007 1.0 0.0
87.5706 -14.6856 14.7592 -3.29481e-007 -1.0 0.0
87.5706 -14.6856 15.7763 -3.3429e-007 -1.0 0.0
84.5891 -14.6856 15.7763 -5.4156e-007 -1.0 0.0
84.5891 -14.6856 14.7592 -6.15459e-007 -1.0 0.0
72.0943 -14.6856 15.7763 -7.63257e-007 -1.0 0.0
72.0943 -14.6856 14.7592 -7.63257e-007 -1.0 0.0
72.0943 -14.6856 16.5219 -7.63257e-007 -1.0 0.0
84.5891 15.0648 16.5219 4.18515e-007 1.0 0.0
106.714 15.0648 16.5219 0.0124515 0.999922 0.0
142.24 6.11993 14.8749 -3.38663e-007 -1.0 0.0
142.24 6.11993 15.2379 -3.38663e-007 -1.0 0.0
136.608 6.11993 16.5221 -3.38663e-007 -1.0 0.0
142.24 -9.11349 14.8749 1.0 0.0 0.0
142.24 -11.1135 15.2379 1.0 0.0 0.0
142.24 -11.1135 14.8749 1.0 0.0 0.0
138.042 6.07494 14.917 0.000837792 -3.65166e-006 1.0
138.015 -9.08779 14.917 0.000855298 -1.52261e-006 1.0
139.886 -9.08779 14.9154 0.000837792 -3.65166e-006 1.0
139.953 13.9443 14.7212 0.395529 -0.00322351 0.918448
137.503 13.9471 15.7763 0.406874 0.00237098 0.913481
139.905 8.13999 14.7215 0.406874 0.00237098 0.913481
134.979 -14.7955 16.0365 -0.00746086 -0.467157 0.884143
134.968 -16.7189 14.9952 -0.0198514 -0.475907 0.879272
136.801 -16.7963 14.9947 -0.00746086 -0.467157 0.884143
144.186 -9.15959 14.6857 0.077911 -0.0395379 0.996176
144.207 -7.38048 14.6878 0.0934456 -0.00229773 0.995622
139.847 -7.34347 15.0971 0.077911 -0.0395379 0.996176
142.32 -9.15389 15.2703 0.299203 -0.000247466 0.95419
142.32 -11.1727 15.2703 0.299446 0.0 0.954113
144.183 -11.1684 14.6856 0.299203 -0.000247466 0.95419
144.138 6.08265 14.6783 0.06736 0.0343132 0.997139
139.966 6.09804 14.9596 0.0800217 0.0625262 0.99483
144.152 4.20161 14.7421 0.0800217 0.0625262 0.99483
137.978 13.9471 14.7592 0.0 0.0 -1.0
137.978 -14.9044 14.7592 0.0 0.0 -1.0
106.714 -14.6856 14.7592 0.0 0.0 -1.0
84.5891 -14.6856 16.5219 0.0 0.0 1.0
87.5706 -14.6856 16.5219 0.0 0.0 1.0
87.5465 15.0648 16.5219 0.0 0.0 1.0
106.714 -14.6856 16.5219 0.0 0.0 1.0
136.62 -14.9044 16.5219 0.0 0.0 1.0
136.62 13.9471 16.5219 0.0 0.0 1.0
139.993 6.09478 14.9154 0.000820285 -5.78072e-006 1.0
137.485 8.21025 15.8349 0.418143 0.00796503 0.908346
139.884 -11.1323 14.6901 0.123533 0.00753448 0.992312
138.014 -11.1323 14.9229 0.0736122 -0.0180455 0.997124
139.937 -14.9248 14.7123 0.0736122 -0.0180455 0.997124
139.863 -9.09379 14.9612 0.0622496 -0.0767137 0.995108
142.24 8.11993 15.2379 0.293413 0.0143911 0.955877
142.32 6.09901 15.2703 0.30569 0.0273603 0.951738
144.184 6.09901 14.6716 0.293413 0.0143911 0.955877
139.968 4.16401 15.1362 0.0926066 0.090679 0.991565
94.2 15.065 16.0699 -1.0 0.0 0.0
94.2 15.8264 16.0699 -1.0 0.0 0.0
94.2 15.8264 15.5494 -1.0 0.0 0.0
101.337 -14.6431 16.1051 1.0 0.0 0.0
101.337 -15.4045 16.1051 1.0 0.0 0.0
101.337 -15.4045 15.5847 1.0 0.0 0.0
106.714 15.0648 14.7592 0.0 0.0 -1.0
136.616 8.11993 14.8749 0.0 0.0 -1.0
142.24 8.11993 14.8749 0.0 0.0 -1.0
136.608 6.11993 14.8749 0.0 0.0 -1.0
136.616 -9.11349 14.8749 -1.69572e-007 1.0 0.0
136.616 -9.11349 16.5221 -1.69572e-007 1.0 0.0
142.24 -9.11349 15.2379 -1.69572e-007 1.0 0.0
137.549 6.07494 15.8209 0.333385 -0.0047163 0.942779
137.522 -9.08779 15.7178 0.320068 -0.00701147 0.947369
139.855 -9.08779 14.9296 0.333385 -0.0047163 0.942779
137.394 -15.5411 14.5527 -1.0 0.0 0.0
137.394 -14.4662 14.5527 -1.0 0.0 0.0
137.394 -14.4662 12.0659 -1.0 0.0 0.0
137.394 13.4005 14.5527 -1.0 0.0 0.0
The complete two files if you wish to study are in MediaFire https://www.mediafire.com/download/4pd9i2qvcf11ns7/stainless_test_meshes.zip
Please don't spend too much time on this Stainless - not many people seem to use Blender as a modelling tool for IL2 - and I only have to do the tedious transfer between computers and manual pasting of data the once .....
-
I loaded both up in my mod tool, and it's very interesting.
(http://s13.postimg.cc/dxbg115lj/image.jpg) (http://postimg.cc/image/x2epask9f/full/)
The one on the left is from blender, the one on the right gmax.
The normals int the blender file just look wrong to me. In the Gmax version you can see many 0,0,-1 and 0,0,1 normals, which is what we would expect on a flight deck.
The ones on the blender version have many like this. 0.707083 0 0.707083 which is approximately 1/sqrt(2) or 45 degrees.
That just looks wrong.
Can you point me at the exporter? I'll have a look and see if I can find the bugs.
-
Gosh Stainless - you're on the ball. Thanks again.
The link to BlendyBlendy Exporter is via one of my previous threads https://www.sas1946.com/main/index.php?topic=43893.0
Direct link is here http://www.solidstate.com.ar/images/bbexporter.zip
You, of course need Blender version 2.49b (not newer) and also need Python exact version 2.6.2 (I guess you run under Windows, if not please see my advice in the thread). I don't think you will find much on the net about BlendyBlendy these days but the manual is quite comprehensive. Good luck.
-
Ok I may have found the problem, I say may. What I mean is I can see a possible source for the problem, I haven't tested anything as I don't have the tool chain.
This function looks wrong to me.
# --- Generate list of reindexed faces and unique vertices and UVs
def generatelists(mesh):
id = 0 #Material ID count
#Declare globals so we can 'write' in them
global vertlist
global faceslist
global uvlist
del vertlist[:] # List of len(mesh.material) lists - List of vertices for each material
del faceslist[:] # List of len(mesh.material) lists - Reindexed faces
del uvlist[:] # List of unique uv coordinates per material
vt = 0 #Vertices sub-total
for ma in mesh.materials:
if ma.name == 'NULL':
id+=1
continue # Skip NULL material
# - Count faces and vertices for each material
fa = filter(lambda x: x.mat == id, mesh.faces)
tempfaces = [] #Temporal list of faces
tempvert = [] #Temporal list of vertices
tempuv = [] #Temporal uv coords
vc = 0 #Vertices count for each material
for f in fa:
temp_fv = [] #Temporal face vertices
for v in f.v:
if (v not in tempvert) or (f.uv[f.v.index(v)] not in tempuv):
tempvert.append(v)
tempuv.append(f.uv[f.v.index(v)])
temp_fv.append(vc)
vc += 1
else:
indexes = [ix for ix, vx in enumerate(tempvert) if vx == v]
for ix in indexes:
if tempuv[ix] == f.uv[f.v.index(v)]:
temp_fv.append(ix)
break
else: # if no match is found then is this face has bad uv projection, add new vertice and uv to list
tempvert.append(v)
tempuv.append(f.uv[f.v.index(v)])
temp_fv.append(vc)
vc += 1
tempfaces.append(temp_fv)
uvlist.append(tempuv)
vertlist.append(tempvert)
faceslist.append(tempfaces)
id+= 1
vt+= vc
return vt;
# --- end generatelists
Specifically these lines.
for f in fa:
temp_fv = [] #Temporal face vertices
for v in f.v:
if (v not in tempvert) or (f.uv[f.v.index(v)] not in tempuv):
tempvert.append(v)
tempuv.append(f.uv[f.v.index(v)])
temp_fv.append(vc)
vc += 1
else:
What that does is take the vertex from blenders face list and save it in a list. The vertex has an attached normal.
From what I remember, this is a smoothed normal. Not what we want in this case. We want face normals.
I'm not an expert at blender scripts, however I think you could just do.....
for v in f.v:
v.no = f.normal
if (v not in tempvert) or (f.uv[f.v.index(v)] not in tempuv):
And that will fix everything.
Is there any mileage in me updating this exporter so it works with newer versions of blender?
-
Had some time to think about it, and I am sure this is the problem.
When you exported from gmax, you had more verts in the mesh. This is an artifact of face normals.
Think of a cube, you have 8 verts and 12 triangles.
If you then smooth the normals, all the normals will be pointing out of the cube along a line through the vert to the centre of the cube. Not what we want. We want the face normals.
To get face normals, we then still have 12 triangles, BUT we need 24 verts. 4 per face.
The normals will then point out from the faces as we expect.
So the only question is, will that one line of code fix the problem.
Down to you to test now ;D
-
Test of bbexporter.py with added line 'v.no = f.normal' did not work, I'm sorry to say. (It was just the one line - right?) Unfortunately, I can't get at the error code in the console because: - my Blender 2.49b runs under PlayOnLinux whose terminal doesn't show any message - and if I start Blender 2.49b with a Linux terminal even the original Python script fails during the export process.
Before I come up with suggestions you ought to know that my last taste of coding was with MS QuickBasic. Anyway, in the bbexporter.py script there is no 'v.no' but just 'v.no.x', 'v.no.y' and 'v.no.z'. Does this matter? Also, I don't see any occurrence of 'v.no' nor 'f.normal' in the loop following the new line.
I suggest that it is not worth spending any effort updating the exporter for Blender - most IL-2 guys use 3DStudioMax or GMax. As I said before, if you can't sort out the bbexporter.py script relatively easily then I can manually prepare my CVA-31 carrier ready for release; it just has to be done once.
-
I've started porting the exporter to the latest version of blender, that may be a way of sorting it out.
-
Are you sure Stainless? I know I will really appreciate it but I think most people are GMax and 3DStudio users. It's up to you ...
I was still trying to obtain the message given by the Blender modified bbexporter.py script failure. I'll stop now but I've just found how to get the PlayOnLinux console working (not at all well documented) then started Blender 2.49b using it (getting round "spaces" and "quotes" in filenames (which for me is good going)) and exported a flightdeck object using the original bbexporter.py. It gave the following error message in terminal -
File "<string>", line 1
execfile(r'Z:\home\me\PlayOnLinux's virtual drives\blender249b\drive_c\Program Files\Blender Foundation\Blender\.blender\scripts\bbexporter.py')
^
SyntaxError: invalid syntax
In a similar test I got the same message using the modified bbexporter.py operation.
If Blender is run from PlayOnLinux's GUI (without starting from a terminal) the original bbexporter.py executes and creates a .msh (with incorrect normals, as you know) but the modified bbexporter.py fails to run correctly.
Good Luck
-
python is a horrid language for one thing, you cannot mix spaces and tabs.
have a look at the lines above and below the one you added
if they start with spaces, make sure the line you have added has EXACTLY the same number of spaces
if they start with tabs, make sure the line you have added has EXACTLY the same number of tabs.
anything else will cause an error
-
I'll look and test later today Stainless (I'm sure I mixed spaces and tabs .....)
-
This line 'for v in f.v:' has 3x tabs.
This line 'if (v not in tempvert) or (f.uv[f.v.index(v)] not in tempuv):' has 4x tabs.
Tested 'v.no = f.normal' with 3x tabs >> crash when BBExporter selected.
Tested 'v.no = f.normal' with 4x tabs >> crash when Export button clicked.
(Also copied line above and line below and replaced with 'v.no = f.normal' just to be sure; same results).
Sorry I can't see any meaningful error messages on the PlayOnLinux console. I know that .... wait .... I'll remove both Blender 2.49b (used for the CVA-31 carrier only) from PlayOnLinux and Blender 2.69 (my main application) from Linux then reinstall Blender 2.49b under Linux. Then we can see the error messages.
It'll probably be tomorrow before I am able to let you know details.
Thanks again, Stainless.
-
Sorry Stainless, even the original BBExporter script in Blender 2.49b under Linux always stops and gives an error message in terminal.
Using Pythonbrew, I managed to install an older version of Python (2.6) under Ubuntu (which normally has Python 2.7.6). In terminal, I forced the use of Python 2.6 and ran Blender. The original BBExporter.py failed and gave the message
File "/home/me/.blender/scripts/bbexporter.py", line 164, in generatelists
tempuv.append(f.uv[f.v.index(v)])
AttributeError: 'tuple' object has no attribute 'index' (I've just found out that Python-speak 'tuple' = a list)
I guess that I didn't manage to get the Blender script to use Python 2.6 and it was using the default 2.7.6. Although Python is supposed to be backward compatible one sees quite a few people on the net wanting to use older versions because of old or unsupported scripts.
Anyway, I've reverted back to Blender 2.49b running under PlayOnLinux and I'll try again and see if I can find any error messages.
-
PlayOnLinux (POL) has a debug facility - and related logfile.
Running Blender 2.49b under POL and using the original BBExporter gives no error message, obviously. Using the modified BBExporter with the line 'v.no = f.normal' included (with 4x tabs) gave the error message -
File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\bbexporter.py", line 44, in write
writehim(ob,parentname,out)
File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\bbexporter.py", line 127, in writehim
writemsh(obj,boxes,hooks)
File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\bbexporter.py", line 288, in writemsh
vt = generatelists(mesh)
File "C:\Program Files\Blender Foundation\Blender\.blender\scripts\bbexporter.py", line 164, in generatelists
v.no = f.normal
AttributeError: 'Blender MFace' object has no attribute 'normal'
Does this help?
-
I've found some more documentation online.
http://www.blender.org/api/245PythonDoc/Mesh.MFace-class.html (http://www.blender.org/api/245PythonDoc/Mesh.MFace-class.html)
It seems that in your "particular" version of Blender, it should be face.no not face.normal.
Whoever wrote Blender really needs a smack in the head. It's a mess. Why do they change everything every time they ramp the version by 0.1?
-
Hey, thanks for your efforts Stainless.
I corrected the new line in BBExporter.py and this time it processed without failure. I exported all the separate objects from the carrier and trialled it in IL-2 but found that there was still a rendering/lighting problem. It didn't appear to be as bad as earlier but, for example, there were two obvious boundaries between the flight deck parts as opposed to the one we had earlier. On the lit side of the island the stack and superstructure have different levels of shading; on the shadow side they are about the same. The liferafts, however, didn't seem to have the odd shading that they had before. Unfortunately, I don't like the extent of the odd lighting/shading even though it is better than what we had before.
So, I will call a halt to the investigation if you don't mind. I will export .3ds from Blender into GMax and export the main mesh entities from there then manually create all the .msh files. Thanks again.
-
Up to you mate.
At least we have made some progress
-
(https://www.mediafire.com/convkey/b5b3/lv82oqdi7cysbkf6g.jpg)
Bonny Dick turning into wind
I tested three more ideas, none of which made any differences to the shading:
1) Moved the vertices so that they were within 0.05mm of each other at the joining flight deck edges (Blender manual input is +/- 1mm).
2) Removed double-sided normals from collision boxes.
3) Removed all LODs, shadows and collision boxes temporarily from the .msh files.
Aaah well, we tried. Unfortunately, because of my mixing Blender and GMax, the Hier.him coordinates are not in harmony and the flight deck is 90deg clockwise, hull1+2 are also misaligned, the shading is not up to expectation so -
I will use Blender and BlendyBlendy exporter with Stainless' fix and ease back some of the texture .mat settings to subdue contrasts.
As I said, we'll leave it here and hope that everyone is content with the rendering.
Thanks once again Stainless for your time and expertise; we are in a better position now than we were three months ago. Thanks.
-
Nice model! Are you sure there isn't somethin funny in the model itself that causes the shading problems? If you want I can take a look at your model to see if I spot something funny. (I do modelling for games as my day job.)
-
And when you publish it, I will have a look and see if I can do anything.
-
Stainless and vvaris - you're both welcome to analyse my CVA-31 model and see if it can be improved in terms of rendering. How do you want it? I currently develop in Blender 2.49 and the whole is held as a .blend file. Blender can export as .3ds or most other formats.
The completed carrier was released last month here at SAS https://www.sas1946.com/main/index.php/topic,46424.0.html
-
It's been a long time, but, the problem is now understood and solved. It looks like it is a VERTEX NORMAL issue where some vertices are carrying 'too heavy a load'. The normal for each vertex should be parallel to it's associated face normal. Ideally separate vertices are required for each face that meets at a corner - giving three vertices at some corners. The uneven textures do not always show up under different rendering/lighting conditions but GMax, Stainless IL-2 Modder and MeshLab can reveal the defect.
To fix a model in Blender: select the Object, Modify /Edge Split /decide a suitable angle, say 88deg /Apply; then go into Edit Mode /select all vertices on the Object /Mesh /Normals /Recalculate Outside; then export Object using BlendyBlendy Exporter. Other methods may be used see http://gamedev.stackexchange.com/questions/7502/how-do-i-fix-this-weird-lighting-problem.
One more thing - check the scaling of objects in Transform Properties (N). If they are different it will probably mess up the lighting in game. To normalize the scale of an object - select object(s), Ctrl+A, Scale to ObData.
This topic is being marked as solved.
EDIT: added scaling fix
-
Cool thing, thanks for sharing the solution to this interesting issue.
Best regards - Mike