Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Dark.Revenant]

Correct.  I'll be adding two more light types in the next update (directional and conical) which will make that easier.

[kazi]

Normal maps are NOT RECOMMENDED.  They are intended for total conversions and special occasions.  Make normal maps AT YOUR OWN RISK!

Normal maps are very time-consuming to make and they should absolutely NOT become the norm for Starsector mods.  ShaderLib is meant to enhance the user experience, not force modders to do significantly more work.  As such, normal maps are disabled by default and must be manually enabled in ShaderLib's settings.json.

eheheheh.


Some broken bits (blender is dumb sometimes), but should be pretty easy to fix. For once I'm not kicking myself over using 3D models.

*edit- fixed the broken bits. Sometimes blender thinks things are "inside-out" when they're not. But yeah, great job on the normal map functions. Just have to start adding these in-game now ^^

[Dark.Revenant]

Yet another update.  There were quite a few problems with the previous version, so if something looked wonky this will definitely have fixed it.

ShaderLib Alpha v1.4

Download Alpha v1.4

(MediaFire Mirror)

Alpha v1.4 (May 27, 2014)
- Fixed normal rotation and direction issues
- Added support for cone-type and directional-type lights
- Added "normalFlatness" option to settings.json
- Removed unnecessary setter methods from LightAPI
- Maximum lights reduced to 372
- Material-mapped hulks now have much less specularity and reflectivity
- Added methods to LightAPI: float getArcStart(), float getArcEnd(), Vector3f getDirection(), float getSpecularIntensity(), float getHeight()
- Added methods to StandardLight: void setArc(float start, float end), void setDirection(Vector3f direction), void setSpecularIntensity(float intensity), void setHeight(float height)

[xenoargh]

Kazi, heh indeed, can't wait to see the results

[Dark.Revenant]

Major update!  No new features so it's not 1.5 yet, but there have been many fixes and now every vanilla weapon and ship has a material map and a normal map.  The normal maps were generated through CrazyBump but are perfectly serviceable.

Screenshots

Spoiler

[close]

ShaderLib Alpha v1.45

Full Edition

Includes vanilla normal maps and high-resolution ripple distortion

Download Alpha v1.45

(MediaFire Mirror)

Basic Edition

Vanilla normal maps not included, low-memory ripple distortion, and performance-optimized default settings

Download Basic Alpha v1.45

(MediaFire Mirror)

Alpha v1.45 (May 31, 2014)
- Added material maps and normal maps for all vanilla ships and weapons
- Fixed weapon material and normal maps (you can now specify whether it is the hardpoint or turret)
- Minor viewport fixes that may improve compatability with other mods that use OpenGL
- Fixed screen scaling issue in windowed mode when the window resolution is equal to the desktop resolution
- Fixed specularity direction error on point, line, and cone lights
- Lights no longer reflect on phased ships
- Re-adjusted default settings
- Split ShaderLib into two distributions: Basic and Full

[Dark.Revenant]

People have asked me whether the material maps and normal maps make a difference.  Decide for yourself:

Spoiler

No Material, No Normal (Except the weapons which still have material maps because it is not trivial to remove them)


Has Material, No Normal


Has Material, Has Normal

[close]

[xenoargh]

Not seeing huge differences there.  You really should add a distant light source and offlight shading, so that there's a clearly-defined lit / shadowed side to forms.  That, and use an example that was built professionally- ask Kazi if he's got anything ready, perhaps- I won't have time to look at this in a serious way for a week or so, due to all the other stuff on my plate atm

[Dark.Revenant]

I am going for compatibility.  Adding a directional light makes the difference between normal-mapped ships too obvious, which is not good for mods involving lots of ships that lack normal maps.

[xenoargh]

If it's done right, with proper normalmaps and a fixed main light / ambient and a material pass that includes self-illum, AO and metallicity in the second texture (I think that metallicity would generally work better than straight shininess, especially if it handled blinn well), the difference will be big and obvious, and that's kind of the point of such a radical departure from the SS rendering core's aesthetic  

I think that the issue is one of largely chicken-and-egg at this point; until there's content made specifically for this, there is no point; but the tech needs some content to develop with and get polished.  If Kazi or the other folks around here with the relevant expertise don't beat me to it, I will try and make that happen as soon as I'm done on the current build of Vacuum, as I'd like to see it- not sure I'd ever have time to do a whole project with it, but a demo, sure. 

This caught me at a bad time, unfortunately, in terms of availability, otherwise I'd have knocked together something already

[Dark.Revenant]

We already have AO and self-illumination because of the existing sprites.  No point making redundant sprites for that.

If you mean specularity with metallicity, then I can make a pass for that kind of map.  Actual metallicity (microfilaments) would require the shader to be made far more complex than it already is.

Also, shading looks very odd with this system because it is a post process effect.  The only way to have "shading" is to have the base be darker by default, which limits color range.  At best, I'd say you can have the shadows be about 25% darker than the base sprite without losing too much color.

[xenoargh]

No, I mean AO, as in a grayscale value that would tone down all specular results from the diffuse + specular + normalmap, and self-illum, as in stuff that is lit even on the dark side.

So, basically (for the material map):

R channel = self-illum, if > 0, then final result = lerp(diffuse, final after normalmap, spec, blah, self-illum value).  A value of 1.0 means that the texel should just equal the diffuse value, so go ahead and halt, if that is cheaper than the branch.

G channel = metallicity (blinn controller ++ factor in base diffuse RGB into final blinn values for a colored-diffraction metal look on blinn highlights if <some boolean uniform> set).  

IOW, use that distant light to push up values in shiny areas with blinn highlights where it makes sense, allow for non-shiny areas (for different material feels, metal vs. plastic vs. rubber and so forth).  Values above 0 get some blinn, 0 value gets normals lit but no blinn and no color range tweaking.

B channel = AO (if value < 1, push final values towards diffuses * ambient via lerp).  Would help preserve height values properly by faking true shadows a bit.  Very important for a professional feel on this stuff; normal lighting / blinn alone doesn't quite cut it.



That is more-or-less how I think it should work, for the material map; that means each ship / weapon / missile uses only 3 textures per pass, which isn't too scary, texture-memory-wise.

Anyhow, that is roughly what I want to do with this.

[Dark.Revenant]

You can already simulate self-illumination by making it a bright spot on the texture but a darker spot on the material map.  You can simulate AO by making a spot darker on the material map (mathematically, there is no difference; a value of 0 on the material map causes the pixel to never be light by lights).  And you get the metallicity color diffraction and specular multiplier through the material map via the material map's color and total luminosity at a given pixel, respectively.  The only thing you can't do is get the Blinn-Phong hardness through material, but this is a small price to pay.

By the way, you can't pass in a boolean uniform per ship because it's a full-screen shader.

If you want to make a TC with this kind of lighting model, you should be able to do it without any code changes, just by replacing the shader files.  However, I will never be using such a high-maintenance model for the vanilla release because it causes material maps to be far more difficult to make and also puts more strain on the modder to create these effects due to the greater perceived difference.  The lighting is deliberately muted specifically so that modders are not forced to make a bunch of assets that they weren't anticipating.

[xenoargh]

Don't worry about it.  Until there's something actually done, it's pretty needless to speculate about it all, tbh; I want to get it to the tech-demo stage and then we'll all have something to talk about

[DornoDiosMio]

Is it just me or does this version use the CPU more heavily than the one I downloaded approximately two weeks ago?  I looked through the settings file, but, did not notice any options which were notated as being CPU intensive.

My GPU is a GTX 460 and it never goes above 50% usage in large battles while using this mod, but, I still get FPS drops.  They are especially common right at the start of a new battle with a good number of ships. It happens at other times as well, but, seems to always be reproducible at the start of a new battle. Sometimes everything is fine after 10-15 seconds, other times it comes back randomly.

I did notice one of the CPU cores was maxed out at 100% and another was rather close to max.  I'm running a Phenom II x4 @ 3.5ghz with 4GB 1333mhz ram.  So, not exactly the newest setup, but, it is good enough that I can put off buying a new computer until I have the money to pay for one, lol.

Mainly just wondering if the heavy CPU usage is normal and if there is anything I can potentially adjust to gain the wee bit of performance I need to avoid FPS drops.  Setting normal maps to false seemed to resolve the issue in some brief testing, but, not entirely.  With normal maps disabled I still had the issue despite the battle being devoid of any vanilla ships. So, I thought that was odd and it is primarily what led me to ask you about the issue.

Anyways, I love the mod and the work you have done on it! Well done my good man!

Note: All settings are at default values with the exception of Normal maps being set to false.

[Dark.Revenant]

Indeed, it does use more CPU because of the try-catch logic required for the makeshift texture loader to work (the alternative is forcing modders to keep extensive data tables for normals and materials) but it shouldn't be using *that* much more CPU.  I just did a profile on my ship-spam arcade mode and all the shaders together used about 7 seconds of CPU time over the course of a 6+ minute run, indicating that about 2% of my i5 2500K core was being used by shaders.  Starsector does not use multicore processing, by the way.

What could really be happening is a texture loading issue, since I believe all Starsector textures are held in RAM even if the GPU loads it, to make sure loading times are short.  Material and normal maps do constitute a non-trivial amount of memory used; for example, with the mods I have enabled (including multiple factions plus vanilla all using normals/materials), Starsector uses 559 MB of texture data, approaching triple that of vanilla.  You only have 4GB of RAM so it could be slowdowns due to your operating system automatically using your swap space rather than RAM for texture loading.  This isn't counting the texture buffers I use for shaders, which can run another 200 MB in some situations, since that is only for GPU memory (they are not reflected in RAM).