Issue with Taranis dock

[Commander_X]

At least the model part is out of the way.
The reason I pointed out the normals, is that what you encounter really seems to manifest like the backface culling technique, where being inside a box -- the dock -- with the normals pointing to the outside, you would not see its faces. This is usually done to quickly eliminate faces that don't need to be textured/rendered.
I'm wondering if there's any effect applied to the dock that would "translate" into this transparency.

[cbr]

When making a model (wings) and selecting an area and make it hole, a look through the hole views the area behind the hole
The hole in the ring does this also and lets you see the ball when pulled through the dock.



A solution could be remove the existing hole, making the ring 'solid' and extrude the dock, means you must re uv map only the area around the
'welcome to taranis'...

[Commander_X]

[...]
The hole in the ring does this also and lets you see the ball when pulled through the dock.
[...]

That shouldn't be the case, as one should see the dock box' (sub entity?) walls. What pkhb encounters is like he never transitions into the dock box, but only inside the ring for the whole docking sequence. At least that's my understanding.

[cbr]

hmm, i noticed a delay between moving in the dock entity and the actual 'warptunnel' which takes you 'inside' the station,
during this delay you see outside of the dock...

[phkb]

hmm, i noticed a delay between moving in the dock entity and the actual 'warptunnel' which takes you 'inside' the station,
during this delay you see outside of the dock...

Correct. If you go in slow you can stop with the dock invisible.

[Commander_X]

[...] Correct. If you go in slow you can stop with the dock invisible.

Yes, what I was trying to say was that you either were inside the dock (with both dock's and ring walls inivisible) or inside only the ring (with the dock -- somehow -- absent from view, and the ring walls invisible). Some of the dock's definition seems to still be in place, as the docking sequence kicks in, but its absence from the view can either have the meaning it's invisible (however that can happen) or it's not there (anymore, that is, you're not inside it -- like it's been pushed somewhere else).

[Cholmondely]

[...] Correct. If you go in slow you can stop with the dock invisible.

Yes, what I was trying to say was that you either were inside the dock (with both dock's and ring walls inivisible) or inside only the ring (with the dock -- somehow -- absent from view, and the ring walls invisible). Some of the dock's definition seems to still be in place, as the docking sequence kicks in, but its absence from the view can either have the meaning it's invisible (however that can happen) or it's not there (anymore, that is, you're not inside it -- like it's been pushed somewhere else).

So how does this apply to the Nuit which Switeck has been writing about? This is a feature of almost all of KW's stations. I especially enjoy this added effect when docking with the Hathor.

And would there be some way of building on it? Say adding a screenshot of a lobstoid customs and excise officer or a long passport queue or a hanger or some such which one sees momentarily? As in NES Elite:

[Commander_X]

[...]
So how does this apply to the Nuit which Switeck has been writing about? [...]

Well, from what I can tell, a common denominator would be the normals being reverted (i.e. pointing inwards for the station, and outwards for the dock), I just confirmed this for the Nuit station.

This is the base in Wings3D:

This is the base in Blender:


Similarly for the dock:



Alas, for any irregularity in the .plist or .js files I have no idea.

[Griff]

I've had the dat to obj convertor script produce obj's where the polygon normals were all flipped from what i would have expected them to be but i'm not sure if it was something in the script doing that or the way my 3d app was interperating the obj model when it loaded it, just wondering if the dat file normals are ok, it's just something in the conversion back to obj that is flipping them?

[Commander_X]

I've had the dat to obj convertor script produce obj's where the polygon normals were all flipped from what i would have expected them to be but i'm not sure if it was something in the script doing that or the way my 3d app was interperating the obj model when it loaded it, just wondering if the dat file normals are ok, it's just something in the conversion back to obj that is flipping them?

That's why I converted to obj (switched normals), back to dat, and a final to obj to re-check the normals status. I didn't do any attempt to check in-game, though.

It is also true that, as I mentioned, the dat files in (some of) these models needed my local Dat2ObjTex file re-crafted, as the UV coords were spaced in a "more relaxed" way than (e.g.) in the OOTB ones. For instance, instead of three tab delimited groups of two space delimited numbers, there were six space delimited numbers. It might be that Oolite's parser is also similarly relaxed on how the dat files are structured.

[Cholmondely]

Just stumbled across this:

Right, just to clarify what I've learned from building my Nuit station...
if you wanna do a new fancy-looking dock :-

- I used dock-flat.dat as a template for sizes : use your modeller to create a box of the same size/shape, and then delete the front face, ie the entrance. Then turn the goddamn thing inside out, or you won't be able to see it.
this box has to be modelled at the origin, (0,0,0). This is the important bit that was doing my head in. for some reason Oolite seems not to recognise a displaced dock model - you have to create it where it expects it to be, and then tell it in the OXP that it has been moved :-/

- do the usual stuff, skinning, DAT converting etc. your ship/station model should obviously have a gap in its wall/hull the same size as the dock entrance.

- in your OXP shipdata plist, the dock will be included as a subentity of the ship/station. give it a name that includes the word "dock", and use the positioning variables to shift the model from the origin to its correct place; this may take a bit of trial and error.
eg:
" subentities = (
"dock-nuit -11.5 3004 421 1 0 0 0","

- the dict definition itself is straightforward. I gave mine the word "dock" in its role too.

and that's basically it.

EDIT - Not sure if this is new during my absence or I just previously avoided it by chance, but on testing a new game asset it turns out that the main game item needs "station" in its "roles" attribute ~ I spent a while wondering why my asset wouldn't rotate and the dock wouldn't work, until I added that alongside my custom role.

[Killer Wolf]

[...]
So how does this apply to the Nuit which Switeck has been writing about? [...]

Well, from what I can tell, a common denominator would be the normals being reverted (i.e. pointing inwards for the station, and outwards for the dock), I just confirmed this for the Nuit station.
...stuff...

Alas, for any irregularity in the .plist or .js files I have no idea.

i have no idea why that looks like it's all reversed in Blender. Nuit, IIRC, would have been modeled in Hexagon, the only stuff i actively had to turn "inside-out" was the interior chambers etc of the hacker asteroids etc. i didn't even mess w/ the dock at the time, and you can see from the textures that the lettering was reversed to get it to look right - way back when i barely knew my way around a vertex