RFC: Fancy classics

[Wolfwood]

Truly excellent work on all the ships in my pack! I'm astounded!

When I get some free time from work, I'll update the wiki entries to reflect this new package.

I'll try these variants on my slower computers as soon as possible to see how they behave and if the results are good, I'll consider dropping my original package completely (unless someone else has already compared the running speeds of these versions?).

I returned to basics and used wolfies model ... though I note that all the models seem to have their center axis about 10cm in (1,1,0) off the z axis. This has been corrected. But - if there was a special reason for this, better speak up.

No reason for that - must be some curious mistake in my modelling program, or the converter that I used to convert the models to a format that Oolite understands (used to cause all sorts of problems, that converter, especially with the Rapier...).

[Griff]

Simon, i just downloaded your neolite.oxp.tar.gz file, i thought i might try copying the shaders into rendermonkey to see if i can spot why the heat effect is vanishing, i'm still cobbling it all together but i've noticed that the anaconda & worm have texture maps of non 'power of 2' dimensions.

anaconda-neolite-default.png 1025x1025
anaconda-neolite-effectsmap.png 1025x1025

worm-neolite-default.png 256x257
worm-neolite-effectsmap.png 256x257
worm-neolite-normalmap.png 512x513

hmm, well the engine effect seems to be working OK in Rendermonkey, at least on the asp ship which is the one i've brought over into rendermonkey to review. one thing i have noticed which isn't a massive problem, is that there is a small level of red and blue accross the whole of the effects map and not just in the areas that you want to glow

this means that the whole of the hull will be affected by the blue channel illumination map meant for the cockpit window and the red channel engine heat glow map, it's not really noticeable though, it's just something i spotted when i was miss marple-ing through your fragment shader code

in line 97 of the fragment shader

Code: Select all

 specular = mix(specular * SpecularRGB, specular * colorMap, 0.0); // Adds the Specular Effect  

the 0.0 means that the mix is 100% in favour of specular * SpecularRGB
i think this is a bug i caused by writing it into an early shader example without really having a clue what i was up too (I still don't!)

if you want you could delete that line to save a bit of processing and change line 107 to

Code: Select all

vec4 color = diffuse * colorMap + specular * SpecularRGB * specIntensity;

so that the specular get recoloured there instead.

[Simon B]

Simon - will you be doing re-models for the Wolf MKII and MK II SE as well?

I havn't seen them - I'll have to look.
They will have to be done sometime, it's just that I've been repeatedly extorted to do whole oxps at once instead of picking a ship here and there. So there will be collateral - like I wanted to do the cobra rapier and had to do the others as well. The main reason for doing them is that they feature in Random Hits - my favorite oxp - since I'm not paid for this, I will do what I feel interested in ... first. Selfish I know.

Note: Ark got skins for his corporate defenders in part because of assistance with the wiki and helping with the oxp dependencies.

There's nothing stopping you having a go ;)

If that's a bit daunting - how about looking for oxps which basically just reskin the classic core ships ... make new skins for the neolite core. Or hunt down incompatibilities.

BTW: the url works now.
It has been hell week for internet over here.

[Simon B]

@Griff:

rogue color - it's odd.
There are lots of ways to convert RGB images to greyscale, the first step in making the effectsmap.
http://www.gimp.org/tutorials/Color2BW/
... I use the "desaturate" option - though, it's not really coded to greyscale, it's really still an rgb image isn't it. Still, GIMP is known to be well behaved in this way.

OTOH: I was not being all that careful constraining colors - especially using radial gradients. So maybe it is just overflow for a gradient, maybe on a different level and I only erased the obvious signs.

I may have to go through and remove the stray colors just to keep the processing down. But it is a very small effect as yet.


texture dimentions - has to be an artifact of the scaling process, but I think the anaconda texture was done at 1024 anyway (have to reread my own tutorial) - that is naughty and shouldn't happen. I'll test it out.
The fix is simple if time consuming and boring - but it does not affect the actual render in the game.


None of this should create the glow-cancelling artifact in the game.

I originally though I was maxing out some value - like if a number restricted to, say, 0.0 - 1.0 turns into 0.0 if the calc puts it greater than 1.

But thanks for the code tweak anyway.

[Griff]

hmm, i'm just not seeing that problem running your shader in rendermonkey,
here's the asp with engine =0.0

and here it is again, with the engine level set to 1.0 (which i think is it's maximum clamped value)


the only thing i can think of is maybe trying a bit of tweaking in this line (line 104)

Code: Select all

vec4 engineEffect = engineAlpha * EngineGlow(min(uEngineLevel, 0.5)); 

you could try changing that 0.5 at the end, that bit of code is passing on to the EngineGlow function whichever value is lower between the 'UEngineLevel' uniform and 0.5, essentially clamping the maximum engine effect to 0.5 because if UEngineLevel > 0.5, the min will return 0.5. if you set it to 1.0 you'll get the full range of engine shades, maybe that will help the effect at full throttle?
BTW, your ships and textures are absolutely gorgeous, seeing them up close in rendermonkey is jaw dropping stuff! the way you've picked out details with the normal map is just spot on, very thoughtful design work!

If you want to go back and take the red & blue out of areas in the map where they shouldn't be, maybe you could mask off those areas using the selection tool, switch to the 'channel view' (you know - the one where the red, green and blue channels get split into seperate greyscale images) and just paint out the red and blue ones with black and a big brush, then when you re-combine the image back into full RGB the red and blue will be gone leaving just the green to control the specular.

[Sendraks]

I havn't seen them - I'll have to look.

Cool, the Wolf MKII & SE sit in their own OXP although the MKII model ( the Wolf MKII paragon) is found in the military fiasco oxp.

The main reason for doing them is that they feature in Random Hits - my favorite oxp - since I'm not paid for this, I will do what I feel interested in ... first. Selfish I know.

Selfish? it is the best and most logical argument to put forward with regards to doing something like this for fun. I'm immensely grateful to everyone who puts time into developing content for Oolite and will continue to be happy and grateful for every ship re-imagining you (and others) do. Long may the process of you doing what you feel interested in most continue, as the results are amazing.

[Simon B]

hmm, i'm just not seeing that problem running your shader in rendermonkey,

But you've seen the problem in the game right?

the only thing i can think of is maybe trying a bit of tweaking in this line (line 104)

Code: Select all

vec4 engineEffect = engineAlpha * EngineGlow(min(uEngineLevel, 0.5)); 

I'll have a tweak.

Though I was expecting the engine colors to be proportional to uEngineLevel up to 0.5 then stay there. I should not see a sudden drop in the effect.

BTW, your ships and textures are absolutely gorgeous, seeing them up close in rendermonkey is jaw dropping stuff! the way you've picked out details with the normal map is just spot on, very thoughtful design work!

On the kiss principle. Though I feel silly posting mostly empty normalmaps.

And you realise that the asp texture is low res?

If you want to go back and take the red & blue out of areas in the map where they shouldn't be, maybe you could mask off those areas using the selection tool, switch to the 'channel view' (you know - the one where the red, green and blue channels get split into seperate greyscale images) and just paint out the red and blue ones with black and a big brush, then when you re-combine the image back into full RGB the red and blue will be gone leaving just the green to control the specular.

Pretty much the plan. Annoying and boring. I don't think I can automate this.

[Griff]

But you've seen the problem in the game right?

i've tested out by hacking a savegame to give myself the asp-player ship, and launching & flying about using external views i'm seeing the engine glow behave as it should, maxing out at about 50% throttle and staying at that level of brightness all the way up to 100% throttle and further (when using fuel injectors.)
i'm on a windows xp pc, running the trunk version of 1.73.

[Simon B]

... this is what I get - but then, I've been delaying the upgrade.

I don't think this is supposed to happen in 1.72 either though. I don't think I should have to mandate 1.73 for neolite.

Oh - I should point out that I do get the flicker effect all the way through.

[edit]
If I remove the min() function - leaving the glow un-capped - the effect goes away.

[Simon B]

Cool, the Wolf MKII & SE sit in their own OXP although the MKII model ( the Wolf MKII paragon) is found in the military fiasco oxp.

Which would suggest a possible conflict. Great.

That's not many ships though, perhaps the two oxps can be merged? Or the mission seperated from the ships?

Actually, wolfies shipdata.plist refers to a mission - I've not looked into that. So I'm sort-of cringing for when people tell me all that it breaks.

It is the small changes and additions which prompt me to consider combining some of these oxps - despite what ark says that I shouldn't.

[Sendraks]

Which would suggest a possible conflict. Great.

The Wolf MKII in the military fiasco is (I think) identified as the Wolf MKII Paragon, which has a different skin to the Wolf MKII and SE variants. I also don't believe it is available as a player ship so, in theory, remodelling the Wolf MKII oxp ships shouldn't (haha) create a conflict with Military Fiasco.

Military Fiasco contains a number of ships and relies on Murgh's X Ships to run properly. I can't see there is any dependency on these for the Wolf MKII oxp to work.

[Lestradae]

I also don't see why any sort of ship that has been remodelled should break a mission in a mission oxp.

Usually, the only thing that could happen would be that the remoddeled ship appears instead of the old model. But that doesn't interfere with any mission as such.

"Worst case" scenario would be if the new version was overwritten by the mission oxp (then you'd only ever see the old one) or that the new version overwrote the mission oxp (only a problem if it was so wildly different from the original that the result made no sense anymore - pretty improbable, that).

I guess this "new ships break missions" idea refers to a pretty improbable event, and should only be thought about on an individual case-by-case basis.

Just my 0.2 Cr

L

[Simon B]

I did say I had not looked at it... and a "conflict" need not be a breakage - exactly. Observe:

... there can be unexpected results. -)

[Lestradae]

I like the neolite Happy Eye Preacher better than the old one.

Where can I download it?

Seriously, if the overwriting of ships according to load order would include subentities, this wouldn't happen.

But I would never suggest changing that in trunk, either A_C will accuse me of killing kittens again. (Don't ask. He knows what I'm talking about)



L

[Simon B]

:lol:

I like the neolite Happy Eye Preacher better than the old one.

This has been represented to me before :)

Seriously, if the overwriting of ships according to load order would include subentities, this wouldn't happen.

It also wouldn't be a problem if all the core ships had only one model.
Which can be done - technically, the ship in your oxp listed as a transporter is the actual neolite shuttle. I expected to be vetoed on the winged version - consigning it to Concepts. Instead, everybody loved it.

Mostly it would involve low poly counts - changing some shapes - and would be quite labour-intensive at this stage. Also, there would be complaints: there are already players who are so accustomed to the neolites that they think of them as the "real" oolite ships.

It is tricky.

If I wanted to make a new skin neolite, the standard approach would be to make a like-ship oxp for it. I can change the skin name in shaders or edit the dat file as per the wiki.

Imagine what a pain it would be to also have to include all the subent entries too? A like-ship plist should only need to include what changes.

However, there is no way to tell it to exclude a subentity that is not wanted. Say I want a sidewinder with different engines - like-ship="sidewinder" will not do the trick. If I want a viper which does not include flashers, or uses different color, then like-ship viper won't work (viper-pursuit will but you see what I mean).

I've thought of having single-model plist entries so other oxps won't always do this. So I can have a shuttle that does not have role="shuttle oolite-shuttle" for the like-ship entries, and the winged-shuttle is what you get from ships called by role.

The trouble will be any other craft which calls the shuttle by entry-name. I'd rather not second-guess or dictate how people structure their oxps ... not too much anyway ;)

@Ahruman?

As it stands, it seems that if I want to change just one aspect of the shader, I have to include the entire shader section.

At this stage, I don't think there is any other project which has a more complete set of internally consistent ships.

Considering previous posts, would someone do me a big favor and catalog oxps which use core and companion ships internally or as like-ships, just with different skins?

With those out of the way, the flamewar constructive and rational debate about how integrated to make neolite can begin.