My first ship...

[Smivs]

Funny thing is I can't decide which is best!

Without shadow of a doubt the top one. Indiscriminately applying smoothing to a model with sharp corners may look nice from certain angles, but from others it will look awful. (For instance, if it’s heading towards the sun there will be a gradient from the front to the back in a way that makes no sense at all for a flat surface.) Just Say No.

The top one is certainly much crisper, but the smoothing does remove that 'stepping' effect that you get on the angles. Is there any way to specify the amount of smoothing? It is possible to add a little bit of smothing to slightly 'round off' the angles?

[DaddyHoggy]

Ahruman already said "no" to that question earlier in the thread. (I think)

Ahruman - PM sent with link to latest .obj file (that creates the .dat file that results in unlit nacelles and wing spikes without smoothing turned on)

[JensAyton]

The top one is certainly much crisper, but the smoothing does remove that 'stepping' effect that you get on the angles. Is there any way to specify the amount of smoothing? It is possible to add a little bit of smothing to slightly 'round off' the angles?

No. The concept doesn’t even make sense.

What smoothing does is average together the normals – that is, vectors defining the “out” direction – at each vertex. For instance, the normal at the nose will point forward and slightly down, while the normals at the rear corners will point outwards and rearwards. The normals are then interpolated across each triangle. (As mentioned above, you can make Oolite show normals using the debug console.)

If you want more control over normals, you need to add more geometry or use normal maps. What you can’t do is magic up detail out of nowhere.

[JensAyton]

Ahruman - PM sent with link to latest .obj file (that creates the .dat file that results in unlit nacelles and wing spikes without smoothing turned on)

OK, there are several problems.

1. Smoothing isn’t working because the script is helpfully interpreting the file in a technically correct way and giving each face its own smooth group. To avoid this, add the line “s 1” at the top of the file (this will put the entire file in a single smooth group).
2. The geometry is broken because the script doesn’t handle non-triangular polygons correctly. If AC3D has a “Triangulate” command, use that before exporting. Otherwise, you’ll need to switch tools.
3. The insides of the nacelles are invisible because polygons in Oolite are one-sided; you need to make the geometry double-sided. (There’s also a gap between the engine and the main fuselage, which shows up as a hole (blue polygons) in Wings, but that’s not a major problem; it will be possible to see through the ship in Oolite, but only with a very precisely positioned camera.)
4. Once all that’s fixed, there will be several smoothing problems. The rear points of the nacelles and pods will need to be capped like the nose. For best effect, you’ll want to add an edge ring just aft of the transition to straight section on the pods.

[JensAyton]

Oh, and one more thing: converting with Obj2DatTexNorm.py gives almost correct results for trunk, including straight edges where you want them, although the tips of the pointy bits aren’t smoothed properly. Triangulating in the source tool should fix this, assuming the result looks good there. The only downside – once 1.74 is out – is that normal maps don’t work properly with meshes converted that way.

[Killer Wolf]

The top one is certainly much crisper, but the smoothing does remove that 'stepping' effect that you get on the angles. Is there any way to specify the amount of smoothing? It is possible to add a little bit of smothing to slightly 'round off' the angles?

No. The concept doesn’t even make sense.

well Hexagon has an increase/decrease smoothing tool that you can use to determine how rounded you want your corners/edges. seemed a sensibly concept to me.

[DaddyHoggy]

Smoothing isn’t working because the script is helpfully interpreting the file in a technically correct way and giving each face its own smooth group. To avoid this, add the line “s 1” at the top of the file (this will put the entire file in a single smooth group).

Top of which file? Apologies for being dense.

I have triangulated model and re-exported as an .obj.

We shall see what we shall see...

EDIT: I made a guess and put "s 1" at the top of AC3D created .obj file before running the obj2dattex.py script.

It seems to have done the trick - with the exception of a few inexplicable oddities - it looks much more as I'd hoped/expected.

Images to follow (RL(tm) requires me to cook tea for the family now).

DH

[DaddyHoggy]

RL(tm): Tea cooked and eaten...

OK - Triangulated but without the "s 1" modification to the .obj file prior to running python script. [Couldn't work out how to double side the surfaces of the nacelles, so duplicated and normals flipped]



Now, triangulated and a single smoothing group ("s 1" added to top of .obj file prior to conversion to .dat)



Odd two surfaces between the nacelle and the cockpit dome - they look OK in AC3D so don't know what's going on there - but being smoothed clearly suits the rounded quality/requirement of this ship...

Right, now to add so illumination - off to get Ahruman's demo cube...

[DaddyHoggy]

OK, so I don't understand how the illumination map works (having downloaded Ahruman's cube demo oxp):



My shipdata.plist looks like this:

Code: Select all

{
   "DH_Rocket" =
   {
      like_ship = "worm";
	  name = "Tycho8";
      model = "tycho8_v5_triangulated_s1.dat";
      roles = "dh_test";
	  smooth = "true";
	  
	  materials =
		{
			"tycho8.png" =
			{
				diffuse_map = "tycho8.png";
				illumination_map = "tycho8_illumination.png";
			};
		};
   };
} 

This is my diffuse map:



and this is my illumination map:



I don't know what I was expecting - I think I thought it would pick up the UV mapping from the diffuse texture - because I only wanted the engine, cockpit and nacelle innards to glow and hence all else is black. (The cockpit and nacelle innards share the same bit of texture just mapped differently)

Don't know why the wings (and the very right hand side of the '8' [not seen in this image]) are glowing green.



[I think my "like_ship" is also incorrect - I just want something that (initially) doesn't have any weaponry - plan was to fiddle with other stats once it was working...]

[Smivs]

New Uber-weapon...blind the enemy while giving them migraine

[DaddyHoggy]

New Uber-weapon...blind the enemy while giving them migraine

It's a cross-over ship - Jonnie Rocket's ship during the week - at the weekend it's used by the Green Hornet...

[JensAyton]

The good news is, that illumination map should work! (Although it would be better to put the glowy bits in an emission map and make the corresponding bit of the diffuse map black.)

The bad news is… apparently it doesn’t. I’m not going to try to do anything about it now, though, because we’re in a srz bzns feature freeze now.

[JensAyton]

well Hexagon has an increase/decrease smoothing tool that you can use to determine how rounded you want your corners/edges. seemed a sensibly concept to me.

…which changes the geometry.

I don’t dispute that modelling tools can change geometry. If they couldn’t, we wouldn’t have any ships to look at. Integrating a complete, plist-driven modelling suite into Oolite would be quite far from sensible, however.

[DaddyHoggy]

The good news is, that illumination map should work! (Although it would be better to put the glowy bits in an emission map and make the corresponding bit of the diffuse map black.)

The bad news is… apparently it doesn’t. I’m not going to try to do anything about it now, though, because we’re in a srz bzns feature freeze now.

because I can't have a glowy ship

because 1.74 will soon be upon us.

How would an emissions map look? How would it go in the shipdata plist?

This isn't just aimed at Ahruman - anybody else?

[JensAyton]

How would an emissions map look? How would it go in the shipdata plist?

Exactly like an illumination map, except it says emission_map. The distinction is that the illumination map value is multiplied by the diffuse map value, while the emission map value is just added. The effect is illustrated here.

Emission maps are both more flexible than illumination maps, and more efficient. In non-shader mode, illumination maps have to be converted into emission maps on the fly. With shaders, there’s still the extra multiplication per fragment.