Jump to content
COMBATSIM Forum

Recommended Posts

Well, for the 0049s with multiple rotations, I created a set of nested transforms and rotated around each axis separately in the order Z,Y,X.

The cockpit still doesn't look quite right though...

 

trrashcpt.png.0da1b62e9fcad09cc201e9c64b1c6206.png

At least most of it seems to be there now. :D

Link to post
Share on other sites
  • 2 months later...
  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Back to the terrain, and I've done an experiment using VRML's Elevation Grid (1025x1025) instead of an Indexed Face Set.

It's basically the same tile (mont1c_1) but is now about 10MB (6.5MB VRML, 3.5MB BMP texture) in size as opposed to a few kB. It looks much nicer though with some mild weathering effects

mont1c.resized.png.7d7d3a328f7943b9f23c4cfb27242c9b.png

 

and even nicer closer in

mont1c_close.resized.png.ff75605c6b5a2b7d217d004b4cc464f6.png

Anyway, Lean Viewer handles it nicely. :thumbsup:

I just need to convert the other 159999 tiles now...and buy a bigger hard disk. :D

Link to post
Share on other sites

No, that isn't feasible, as a few of those tiles would have the same total number of vertices as the current terrain.

This is more for my own personal enjoyment where converting each terrain tile to a heightmap and texture allows for some experimenting with 'standard' tools.

Here I'm using World Machine to slightly modify the terrain around Luxor.

lux1.png.49a08ed1c15ebe69002f691e5d004566.png

 

A bit pointless really, but it was either do this or go to IKEA. :D

Link to post
Share on other sites
On 8/18/2019 at 10:51 PM, mikew said:

Back to the terrain, and I've done an experiment using VRML's Elevation Grid (1025x1025) instead of an Indexed Face Set.

It's basically the same tile (mont1c_1) but is now about 10MB (6.5MB VRML, 3.5MB BMP texture) in size as opposed to a few kB

I forgot that Lean Viewer can use PNG files for the texture which reduces the 3.5MB 1024x1024 bitmap into the ~100kB range.

It would be good if the Elevation Grid could be handled in a similar way, but as far as I can see, it is always handled as text. Maybe the complete VRML file can be compressed though.

Link to post
Share on other sites

This will only be the import format – the engine will cache imported models in an internal format. This way you don’t have to worry about mesh compression, block compression artifacts or efficiency of compression algorithms depending on the speed of the underlying data storage :)

Link to post
Share on other sites

It's more about how a TFX terrain sized terrain would be handled if we wanted more variation, ultimately with every tile unique.

 

As an experiment, I created 160000 tiles, each with a 2048x2048 elevation grid compressed into .hfz format and a 1024x1024 texture compressed to .png. It took about 8 hours just to create the files and the resulting directory took up about 16GB of disk space.
That didn't seem too bad without any optimization, apart from compression.

 

What was interesting, was that if I right-click in and select 'Properties' of the resulting directory in Win7 or Linux, I get an instant answer of 320000 files and the total size. With Win10 it takes seemingly forever to get the same result.

 

Link to post
Share on other sites
  • 3 weeks later...

Had another look at simplifying the terrain by baking in whatever is on top of the base texture of the tile. There is a problem with thin things like roads and railways though, in that the single texture needs to be quite big to get anywhere near the definition. It's not too bad with 2048x2048, but not sure whether this is the way to go...

An example is rlarbs_1.3, where on the right you see the road/rail texture z-fighting with the base texture if I just blindly convert the polygons to VRML.

On the left, I've blended the road/rail polygons with the base texture into a 2048x2048 buffer and saved it as a png file.

rlarb_1.png.752d1214d243d97e450fe5f5443a0a52.png

Link to post
Share on other sites
  • 9 months later...

I've rewritten most of my VRML parser for my own personal enjoyment and the cockpit geometry seems to work now. It's not quite usable as it is because there is a big polygon that cuts through the pilot and MFDs in the VRML version. It took a while to work out why it was OK in the 3View version.

Also, transparency is going to need some effort as I can't just define a texture as a transparency mask in VRML. As I understand it, VRML needs an alpha channel.

vrcpt.png.d68036591189eef02b501fee420977ee.png

Link to post
Share on other sites
1 hour ago, mikew said:

I've rewritten most of my VRML parser for my own personal enjoyment and the cockpit geometry seems to work now. It's not quite usable as it is because there is a big polygon that cuts through the pilot and MFDs in the VRML version. It took a while to work out why it was OK in the 3View version.

Amazing 😃

 

1 hour ago, mikew said:

Also, transparency is going to need some effort as I can't just define a texture as a transparency mask in VRML. As I understand it, VRML needs an alpha channel.

Yes, this is desired because no modern GPU supports color keys or palette tricks. We should rather go full alpha :)

Link to post
Share on other sites

What about a step-wise transition process whereby you become comfortable, first, with what TFX gives us in the way of alpha, and then expand to a more comprehensive script to convert the terrain and other transparency masks? TFX gives us the rules/code for AGP alpha but only for the explosions. The good news is that it is 32-bit color with the format BGRA and the .3 instructions are right there. Bad news is the textures are only 64x64 BGRA8888 and a progression to create and include larger textures would be semi-necessary. With your skill set I would think you could make that work with your VRML project?

Link to post
Share on other sites

What I'm doing now is a continuation of what we were discussing two pages back in this thread (around Sep 2018)...but with better functioning code. That Rameses monument looks Ok now, and while the priority is the terrain and ground objects, some of the vehicles are starting to take shape as well.

varmodels.png.da109e53f3089002e2c19db60a3372ec.png

That radar picture shows the ways that transparency is used in TFX3. All the textures are paletted .bmps converted from TFX's .tm and .col files.

Luckily, Lean Viewer is interpreting palette position 0 as transparent, so we see through the outer layer of the base of the radar. I think I can handle this with RGBA by giving anything with palette position 0 an A value of 0, and 255 for the rest...as long as palette position 0 is not used as black in certain circumstances.

That radar picture shows the polygon used as the transparency mask used for the shadow. This will be culled later but this will never display properly, as the transparency mask is being put on the same plane as the underlying texture. I think the transparency mask should work for the parts of the cockpit though but it may require some effort to find out which parts of the textures are used for this and treat them separately. I'm guessing the transparency masks are never used as ordinary textures...

Link to post
Share on other sites
52 minutes ago, mikew said:

Luckily, Lean Viewer is interpreting palette position 0 as transparent

That’s news to me :D

 

53 minutes ago, mikew said:

I'm guessing the transparency masks are never used as ordinary textures...

I think so – only for special stuff like the arrows on the canopy (seen from inside), clouds, smoke, etc.

Link to post
Share on other sites

The lazy way to handle transparent textures is apply the 'transparency rules' to all textures, whether they are used for transparencies or not.

This results with a new set of RGBA bitmaps (.bmp) based on the palette index values of the original .tm files with a "t_" prefix to distinguish them from the original textures.

Now if I open the .bmp in Lean Viewer, I see the alpha is working. I've marked the area that should be used for the building shadow and this looks OK. In this area, the RGB values are zero, as fully opaque should give black.

The shadows are completely missing though. The VRML code is the same, except for the name of the texture called from the examples earlier where the shadow appears as a multicoloured polygon.

luxtower.png.a4877430018af46f73dc9f6bba84b5dc.png

 

Link to post
Share on other sites
7 minutes ago, mikew said:

In this area, the RGB values are zero, as fully opaque should give black.

I thought that might have given a clue, so I made the base colour RGB 111 instead.

This time I see the shadows, but not the transparency gradient.

luxtowers.png.0de89ee0d7a2d29fe66b5f876222f2c6.png

Link to post
Share on other sites
11 minutes ago, mikew said:

The lazy way to handle transparent textures is apply the 'transparency rules' to all textures, whether they are used for transparencies or not.

This results with a new set of RGBA bitmaps (.bmp) based on the palette index values of the original .tm files with a "t_" prefix to distinguish them from the original textures.

Incidentially, that’s what my TFXplorer renderer does internally :)

 

11 minutes ago, mikew said:

Now if I open the .bmp in Lean Viewer, I see the alpha is working. I've marked the area that should be used for the building shadow and this looks OK. In this area, the RGB values are zero, as fully opaque should give black.

The shadows are completely missing though. The VRML code is the same, except for the name of the texture called from the examples earlier where the shadow appears as a multicoloured polygon.

Oh no, that’s my fault! Lean Viewer doesn’t support any alpha yet; it only supports color keying (i.e. 100% or 0% transparency per pixel). Half-transparent pixels are rounded either to full transparency (what you see) or to full opaqueness.

 

The reason is, transparency requires sorting by distance, and Lean Viewer doesn’t have this yet …

 

… maybe you can, until further notice, just pretend the alpha was there? From your analysis I’m sure your textures are actually correct!

 

(I just now realize that I never before used Lean Viewer with a project that has actual alpha. This should have come to my mind earlier; sorry!)

Link to post
Share on other sites

Aha! That explanation fits in with what I'm seeing. Thanks!

34 minutes ago, Krycztij said:

… maybe you can, until further notice, just pretend the alpha was there?

Of course! I was going to cull the shadows at a later stage anyway. It would be nice to see the transparent bits of the cockpit though.

I'm sure we're probably reaching the limits of computer graphics technology. :D

 

I'll move onto the next problem area for now...

Link to post
Share on other sites
  • 2 weeks later...

Going back to my tile texture experiments and I'm having some transformation issues.

For Luxor airbase, we have the tluxor tile with its base texture and 'scruff'.

According to 'the rules', the next shape in the rendering order is the taxiway, and I've blended that onto the tile.

This is slightly offset in x and z, rotated 20 degrees but not scaled.

Next comes 'rwymid01.3' which consists of 4 submeshes (002d opcode for displacement) with offsets in the z axis. I think that part is OK.

The SSD then rotates, offsets and scales the shape for placement on the tile.

Any idea which order that should be done?

I'm doing the 002d offset first, then the SSD rotation, then the SSD offset and finally the SSD scaling for each vertex.

The runway isn't quite lining up though...

lux_bad.png.3c05d08963deaf4105bc4aeb475b9c5e.png

I'm having trouble getting 3view working for luxor.ssd to see whether the runway should be crossing the middle of the tile like that.

It may be that the taxiway is in the wrong place as well.

 

Link to post
Share on other sites

				Geo::Matrix4x3_float_reg shapeToWorld;

				// First, rotate the shape. Most of TFX’s shapes (especially those in landscapes) are not rotated at all, so a few
				//  hundred cycles per shape can be saved here.
				if(0 == toObject->roll && 0 == toObject->yaw && 0 == toObject->pitch) {
					shapeToWorld = Geo::Matrix4x3_float::identity();
				} else {
					// Angles are given as normalized integers in the range of [0, 65535]. “rollPitchYaw()” expects its angles as
					//  normalized integers in the range of [0, 2³² - 1], which equals a multiplication by 65536, which equals a left-
					//  -shift by 16 bits.
					Geo::Angle4B const roll  = {     UInt4B(toObject->roll  << 16u) };
					Geo::Angle4B const pitch = {     UInt4B(toObject->pitch << 16u) };
					Geo::Angle4B const yaw   = { 0 - UInt4B(toObject->yaw   << 16u) };
					shapeToWorld = Geo::Matrix4x3_float::rollPitchYaw(roll, pitch, yaw, Geo::XYZ_float::zero());
				}

				// Then, scale the shape. Most of TFX’s shapes are not scaled at all (usually, the 0030 instructions in the
				//	shapes take care of correct scaling), so a few cycles can be saved here.
				if(1 != toObject->scale) {
					auto const scaleFactor = (0 < toObject->scale)
					                       ? float(toObject->scale)
					                       : -1.0f / float(toObject->scale);
					shapeToWorld.c0 *= loadx4(scaleFactor);
					shapeToWorld.c1 *= loadx4(scaleFactor);
					shapeToWorld.c2 *= loadx4(scaleFactor);
				}

				// Translate the shape to the destined position.
				shapeToWorld.c3 = asFloats(asSInt4B(loadx4(&toObject->xyz.x)));

				store(toObject->shapeToWorld, shapeToWorld);

where roll/pitch/yaw is

//      cos(r) -sin(r) 0        1     0      0          cos(p) 0 sin(p)
//      sin(r) cos(r)  0    ×   0  cos(y) -sin(y)    ×     0   1   0
//        0         0  1        0  sin(y) cos(y)       -sin(p) 0 cos(p)

I tried using TFXplorer, but without place names I have trouble finding the tile :(

Link to post
Share on other sites

Thanks, that was helpful!

 

I had at least two errors. The main one being the realization that I'm rendering to a texture, so the origin is top left, not bottom left. That meant everything else was wrong until I got the z-axis sorted out.

Link to post
Share on other sites

Anyway, this is a stupid idea.

The last layer is the runway markings. These are coloured polygons and while there should be continuous whitish lines running down the sides of the runway, they are reduced to a few dark dots when scaled down to the required size and rendered to my 2048x2048 bitmap.

I could make the bitmap bigger, but I think I'll look for a smarter solution.

lrwy.png.051ccb402aa5f5e578b7b4ef8c83fa6c.png

Oh, and I see the runway still isn't correctly lined up with the taxiway anyway...

Link to post
Share on other sites

Not sure where that black border came from, but I work on that texture multiple times as I build up the layers and I think I've lost the alpha channel along the way.

It's something I was going to worry about later if the approach showed any promise.

The fun part was working with OpenGL's new fixed function pipeline. It avoids having to deal with complicated things like shaders. :)

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...