Question ASCII-3 (Lua Script J-3 with mesh made with Notepad) Adventures and Questions

[Thunder Chicken]

Associating the normals with the vertices allows the renderer to 'shade' the triangle based on the different normals at its 'edges' (the vertices). Its how our low poly meshes look smooth.

So it's not really exactly the vector normal, but something that weights the shading across a triangle. Blech.

So if you are actually interested in rendering a distinct, sharp corner, you need to have duplicate vertices at the corner, with one set of vertices associated with one surface pointing normal to that surface, and a second set of vertices with a different normal direction applied to a different surface.

 

[Blake]

So it's not really exactly the vector normal, but something that weights the shading across a triangle. Blech.

So if you are actually interested in rendering a distinct, sharp corner, you need to have duplicate vertices at the corner, with one set of vertices associated with one surface pointing normal to that surface, and a second set of vertices with a different normal direction applied to a different surface.

Yep.

 

[Thunder Chicken]

That's a nuisance. There is no way to reuse vertices for different faces because of this normal definition. I'm not building anything exotic here, but this just leads to bloated mesh files.

You could have non-linear vertices 0, 1, and 2 and define one side of a 2D face and its normal with 0 1 2, and the opposite face definable with 0 2 1. Three vertices, two faces, and two mathematically defined normals.

But because of the Orbiter "normal" definition, you now have to have six vertices, even though the extra three are exactly the same vertex coordinates, and you need to define six "normals" for all six vertices, and they really aren't mathematical normals but something that just soften curves visually, so they'd make a mathematician want to throw things.

Why couldn't it be done by using face normals, and then just creating an option for whether the face normals would be used for the shading of the entire face, or another option where the face normals are used to apply a shading weight to each vertex based on adjacent normals? That keeps everyone happy and reduces the vertex count?

 

[Blake]

Its a nuisance if you are building models by hand...nobody does that.

I imagine there are rendering engines that can work as you describe. I believe Orbiter was heavily influenced by what DirectX supported, which is the vertices list and the triangle definitions using that list. For large 'organic' models I'm sure that is more efficient for the render engine to handle.

Blender handles it different still, associating normals with the triangle list and not the vertex directly. The Blender plugin actually has to add vertices if it sees a hard corner like you describe, for the reason you are stating.

 

[DaveS]

Its a nuisance if you are building models by hand...nobody does that.

I imagine there are rendering engines that can work as you describe. I believe Orbiter was heavily influenced by what DirectX supported, which is the vertices list and the triangle definitions using that list. For large 'organic' models I'm sure that is more efficient for the render engine to handle.

Blender handles it different still, associating normals with the triangle list and not the vertex directly. The Blender plugin actually has to add vertices if it sees a hard corner like you describe, for the reason you are stating.

Exactly. The only one I have in my 21 years as a member of the general Orbiter community and add-on developer heard of making meshes by hand is the good Doc himself(his LC 39 pad meshes are those meshes). Everyone else, including me has used some kind of actual 3D modelling program (myself, I have used Anim8or, GMAX and AC3D) that has an *.msh import/export script. Writing a mesh file by hand is half-way insane if you ask me.

 

[Thunder Chicken]

Its a nuisance if you are building models by hand...nobody does that.

Here at Thunder Chicken's Handcrafted Artisanal Meshes we do!

Writing a mesh file by hand is half-way insane if you ask me.

Only half? Oh, good!

 

[Thunder Chicken]

And, since the vertex "normals" are really just weighting functions for the shader, they must be unit normals as both the magnitude and direction matter. Otherwise things like the left wheel strut get really shiny (yes, I am calculating face normals with the other half of my sanity):


Normalized:

 

[Thunder Chicken]

That's more like it.

 

[Thunder Chicken]

Calculated all of the normals by hand.

 

[Thunder Chicken]

And she flies! All J-3 data is used for aircraft specifications and it flies appropriately. I am considering an air-breathing reciprocating engine model to get realistic engine and propeller thrust like my jet engine add-on, but right now it's just flying on a thruster with about the right thrust magnitude to put it around 100 KIAS max speed. I might tinker with adding an animated prop.

So why did I do all this? I am interested in making add-on performance models for engines, aerodynamics, etc.. for various aircraft types (jets, propeller aircraft, helicopters, dirigibles, etc..), but I really only need simplistic aircraft meshes of different types to get some physical understanding of what the vessel is doing for flight testing. Low poly meshes that look like they fell out of a 32 bit machine are fine by me. I could certainly just dive into learning Blender and have it spit out a mesh, but I knew what I was looking for was going to be pretty simple geometrically and now I have a better understanding of the Orbiter mesh format after doing it manually.

Now that Lua is usable for vessel addons, one can actually make vessel meshes and addons for Orbiter with only a text editor and some comfort with geometry and left handed vector math (a spreadsheet helps too, for tracking the vertices and calculating the normals and such, trig functions for wheel points, etc.). That is interesting to me, that someone doesn't need to learn a bunch of different softwares to do something in Orbiter - just an ability to understand geometry and numbers and manipulate a text file can do it.

When I get this polished up to my liking I'll release it. Having fun so far.

 

[Thunder Chicken]

Now with animated propeller. I made a twisted blade prop in a spreadsheet and defined the vertices, triangles, and normals by hand.

 

[Buck Rogers]

crazy but cool
Very interested in the propeller engine module, will it support combustion and electric (would be great for accurate ceiling etc. for VTOL (drones))?

 

[Thunder Chicken]

crazy but cool
Very interested in the propeller engine module, will it support combustion and electric (would be great for accurate ceiling etc. for VTOL (drones))?

That's the general hope, though I haven't looked hard at the details yet. Certainly getting a propeller thrust model independent of the powerplant will be a major part of the model. Getting it to play nicely with the different powerplants will be the next major effort.

 

[Thunder Chicken]

Tooling around over Massachusetts.



Still just have a thruster mimicking the propeller and slapped some annotations up to get basic instrument information in ICAO units. Aerodynamic model seems to be fine. Top speed ~90 kts (85 kts per actual data), stalls at 35 kts (38 kts per actual data, I put the USA-35B airfoil data into the model).

It flies properly. You need to know where the rudder is to coordinate your turns. I am using my autopilot MFD to coordinate the turns as I am on a keyboard, which needs some tweaking as it was designed for a Mirage2000, but it does work. I might bake the auto-coordinate feature into the model as it really is not possible to fly by bank-and-yank.

The mesh is visible from the cockpit view which puts you in the airplane. I'd really like to get a basic steam gauge instrument cluster into the instrument panel. I don't know if a full virtual cockpit is necessary if I can just mesh and animate it right in the vessel mesh. Not sure if that would be a good or bad idea. I've never made an instrumented cockpit before, virtual or otherwise, so I have some learning to do. I'd like to find some standard instrument faces that I can use. I'd like to make a better propeller too, but making it super realistic is a lot of polys relative to the rest of the vessel and that seems silly. I am thinking of something like the plastic propellers that come with the rubber band powered Guillow's kits. I actually built their Super Cub kit back during COVID so I can probably pull some vertices off that prop.

I'm thinking if I can tidy up these items, I could release this J-3, and modeling other light aircraft should be pretty straightforward. Might start a Low Poly Air Force.

 

[Thunder Chicken]

So now I am looking to learn about how to implement textures. Here is what I have done so far:

• I made a bitmap (in attached zip file) with dimensions 1024 pixels wide and 256 pixels high (both powers of 2) with a transparent background.
• I opened the bitmap in GIMP and exported it as a .dds file (also in attached zip file).
• I put the .dds file in Textures/J-3
• In my mesh file, I have a single group that triangulates the flat instrument panel. At the bottom of the file I entered the path to the texture as shown:

TEXTURES 1
J-3\panel_texture.dds

• In the instrument panel group I set TEXTURE to 1:

LABEL Instrument_Panel
MATERIAL 5
TEXTURE 1
GEOM 4 2
-0.358 0.102 0.895 0 0 -1
0.358 0.102 0.895 0 0 -1
0.102 0.256 0.895 0 0 -1
-0.102 0.256 0.895 0 0 -1
0 3 1
3 2 1

But this is what I get when I load the mesh in Orbiter:



The texture seems to be rendering everything behind it invisible like some sort of Looney Tunes hole in a wall. Shape and location are correct, but it should look like this (it's a quick practice texture):



What am I missing?

 

[Buck Rogers]

Where's the material 5?

Also take a look at Orbitersdk/Utils/Shipedit, not only does it calculate cross sections and PMI etc., but it also scales meshes and... generates normals?

 

[Thunder Chicken]

Where's the material 5?

Listed in the materials at the bottom of the mesh file:

MATERIALS 6
Cub_Yellow
Clear_Glass
Tire_Black
Shadow
Panel
Wood
MATERIAL Cub_Yellow
0.5 0.35 0 1
1 0.7 0 1
1 1 1 1 80
0.1 0.1 0.1 1
MATERIAL Clear_Glass
0.1 0.1 0.1 0.5
0.2 0.2 0.2 0.5
1 1 1 1 10
0 0 0 0
MATERIAL Tire_Black
0.05 0.05 0.05 1
0.1 0.1 0.1 1
0.05 0.05 0.05 0.05 10
0 0 0 0
MATERIAL Shadow
0.05 0.05 0.05 1
0.1 0.1 0.1 1
0.05 0.05 0.05 0.05 10
0 0 0 0
MATERIAL Panel
0.1 0.1 0.1 1
0.2 0.2 0.2 1
0.1 0.1 0.1 0.1 10
0 0 0 0
MATERIAL Wood
0.54 0.13 0 1
1 0.26 0 1
1 1 1 1 80
0.1 0.1 0.1 1

Also take a look at Orbitersdk/Utils/Shipedit, not only does it calculate cross sections and PMI etc., but it also scales meshes and... generates normals?

The mesh is all done. I scaled it in a spreadsheet, wasn't hard. There aren't a lot of vertices. However, I did want to use shipedit.exe to get the areas and PMI for another add-on, but it doesn't seem to want to run for me on Linux anymore. I have used it, not sure what the problem is. It's not a big deal for this J-3 add-on as the projected areas aren't needed in my add-on as I am not using the legacy drag model, and the PMI would be problematic as the actual J-3 was mostly hollow, so integrating the volume like it is solid isn't correct at all. Most of the mass is concentrated in the engine and passengers in the cockpit, so I could calculate something sensible from that by hand.

 

[Buck Rogers]

Which way are the normals facing on the panel? (your material is very dark for using a texture, an off white is normally good, but it shouldn't appear invisible?)

 

[Thunder Chicken]

The panel normals are directly in the -Z direction. This is the group:

LABEL Instrument_Panel
MATERIAL 0
TEXTURE 1
GEOM 4 2
-0.358 0.102 0.895 0 0 -1 0 0
0.358 0.102 0.895 0 0 -1 0 0
0.102 0.256 0.895 0 0 -1 0 0
-0.102 0.256 0.895 0 0 -1 0 0
0 3 1
3 2 1

I made an error in the material I indicated above. I set MATERIAL 0, which makes the invisible hole. Material 5 was the material I used previously to render the panel mesh.

I read in the documentation that uv coordinates are needed for the vertices, and from looking at other meshes it seems 0 0 is a default which is what I applied to these vertices. It made no difference, and I tried 1 1, 0.5 0.5, and no change with those either. Really not seeing what I am missing.

 

[Buck Rogers]

This is froma similar object (ignore the flag), the UVs look different?

LABEL huddisplay
MATERIAL 11
TEXTURE 0
FLAG 7
GEOM 4 2
-0.0750 0.8638 2.6239 0.0000 0.0000 -1.0000 0.0000 0.0000
0.0750 0.8638 2.6239 0.0000 0.0000 -1.0000 1.0000 0.0000
0.0750 0.7138 2.6239 0.0000 0.0000 -1.0000 1.0000 1.0000
-0.0750 0.7138 2.6239 0.0000 0.0000 -1.0000 -0.0000 1.0000
2 3 0
1 2 0