Project FL


#21

Since my project is focused in graphics and walkmeshes belongs to AI, it’s out my scope, but if in the future we come to that, we could evaluate this: https://github.com/recastnavigation/recastnavigation. It’s an open source state of the art navigation mesh construction toolset for games.


#22

Two other thing coming to my mind that should be related to the graphic side.
Having exterior sky for interior.Could allow to do some exterior tileset more optimised for city and quicker to build for mapper.
Having light like torch working on tree/grass.(or i missed the option?)


#23

I worked on ensuring that I was interpreting the graphics values of areas, tiles, placeables, lights, etc. correctly. For that, I used the graphics equations that I think NWN2 used, which I guess they are the classic ones before PBR age, in the expectation that I would get a similar effect. I think that I succeded:

This is the baseline upon which I’m going to build future improvements.


#24

That’s actually amazing… Lol…

But why do you want to be identical to NWN2? NWN2 lighting is fantastically bad at times. No shame in improving it.


#25

If you expand things, we could use eliminating the 6 light spheres per tile limit.


#26

The lighting system for NWN2 interior areas seems to work differently than for the exterior. Interiors seem to significantly decrease in luminosity beyond a certain range. Another thing that happens with interior tilesets is that an overhead dome gets blacked out where it overlays a solid (ZZZZ) tile. The same thing happens with the floor packet of ZZZZ tiles (which I sometimes use, for example, for an enclosed chamber with no doors).

Not that these details particularly matter for this project. Just sayin’.


#27

I don’t want to be identical to NWN2. I wanted to achieve a similar rendering to proof myself that I was interpreting the graphics values correctly and use that as a base reference to compare against future graphics enhancements.


#28

Currently my engine doesn’t have a light limit other than the performance overhead that it’s tolerable. Although I think that establishing a light limit could be useful to guarantee that areas have an acceptable performance on several PCs. But I have no strong opinion on this.


#29

Hi, Trinital. Could you tell me examples on how NWN2 lighting is bad? I would like to know examples on which I can focus improvements.


#30

I know I’m not Trinital (:smiley:), but I can offer one that sticks out for me: the mediocre shadow-casting algorithm. There’s at least three examples in the image below:

The furniture above has solid sides, but manages to let some light streaks pass through. Despite being at ground level, the character at the bottom has a gap past the shadow-casting foot and her shadow.

In the game options I have the Shadow Options setting at high and the point source and softer shadows checkboxes selected.


#31

That’s some usual flaws of shadowing techniques. Even today, there isn’t a shadowing technique for games that doesn’t have flaws. I will see if I can get it better that original NWN2.


#32

Hello FL,

Your project is really interesting ! Implementing PBR textures would indeed be a really nice addition, but it would also be nice if you could do something about the polygon limitation. Having an engine capable of managing models as detailed as some modern games would have a major impact on the visual quality of this game, I think.

That said, in my experience, the NWN2 engine is still capable of displaying some nice things, despite its venerable age :

This is a picture of my (currently under development) interior tileset. As rj said, the shadow casting is rather mediocre, it’s clearly visible on the different tiles elements, like the ceiling and the wall beams, for example. If you allow these parts to cast shadows, you’ll get some strange results, with shadows being cast on opposite sides of the walls… not sure if you can do something to fix that.


#33

Another problematic graphical feature that sticks out for me is the impact of ground lighting, which can make a character’s face and possibly other body parts look ugly. Why does dark brown ground lighting override the other light sources? It often looks better just to turn that off, or at least tone it way down.


#34

EDIT: Just saw rjshae’s post. That was exactly what I meant.

The dynamic lighting and global lighting light normals completely different.

I would say NWN2’s dynamic lights are pretty okay (What you demo’d in your level), they respect Normal mapping correctly and refract decently well for an engine this old.

The Global lighting (Skymap Lighting / Area lighting, whatever you wanna call it) is horrendously bad. It’s some kind of Gamma Space lighting scheme that quickly pushes diffuse / normal map textures to white. Also it sometimes lights meshes incorrectly…

All my best examples are NSFW… but it happens a lot around the seams of character models… Like I have spent a good few months working on resolving neck seam issues between heads and bodies for NWN2 and the normal mapping around that under global lights has been a nightmare.

(It feels like the “global light” is actually using a different tangent space than dynamic lights… I don’t know how to describe it, the light looks like it’s coming from under the neck when the source is actually over the character)

Again I have really good examples of this but they are… uhmm… NSFW content.

If you were to implement a linear lighting scheme… maybe…?

Other Rando Stuff Semi-related to lighting:
Glow map intensity (painted through the alpha channel) Only has 4 intensities (0 25% 50% 100%) Same with spec mapping (painted on the alpha channel of normal maps + based on the material in the mdb)


#35

The MDB format supports until 65536 vertices per mesh (because vertex indices are 16 bits) and around 2 billions of triangles (because packet size is 32 bits). Does the NWN2 engine have hardcoded limits below these ones or is the problem mainly performance?

My engine has a limit of 65536 vertices per mesh. Number of triangles isn’t limited (besides going out of memory, of course).


#36

Global Illumination

I think how ground light and sky light exactly work, because it was an important part in order to match the shading of my engine with NWN2. Ground light approximates light rays comming from all directions from a south hemisphere. So it lights polygons even if they aren’t facing the ground. Sky light is the same but from a north hemisphere. This system is a basic simulation of global illumination. It also has been
used by artists as a kind of global tinting.

Modern global illumination is one of the most difficult things to do, but I’m also very motivated in working on it because I think it’s one of the things that’s going to improve the graphics the most.

Alpha channel of textures

The limit of 4 intensities could be because of using DXT3 texture compression, which has low alpha precision. Have you tried DXT5 or uncompressed?

My engine is more flexible because you can make your own shaders and supports modern texture compression formats with higher precission.


#37

The MDB format supports until 65536 vertices per mesh (because vertex indices are 16 bits) and around 2 billions of triangles (because packet size is 32 bits). Does the NWN2 engine have hardcoded limits below these ones or is the problem mainly performance?

My engine has a limit of 65536 vertices per mesh. Number of triangles isn’t limited (besides going out of memory, of course).

You get some weirdness happening around the ~30 000 poly limit… Artifacting on normal maps, or faces not rendering correctly. (Blacking out or getting “spidery webs”)

The highest asset mesh in the base game is around ~6000 poly’s. Also the toolset lags a lot if your placeables reach over 3000 - 4000 poly’s. Although character models can handle much higher. Something weird about the toolset I think.


#38

The limit of 4 intensities could be because of using DXT3 texture compression, which has low alpha precision. Have you tried DXT5 or uncompressed?

Well what about tga formats? Those are quite common and have the same issue.

(You are correct though, for most of my textures I am using DXT 3)


#39

Another graphics issue is the flickering that occurs when the faces from two different meshes share the same plane. One can get that effect even from completely transparent meshes like a walk mesh helper. Not sure how you would tackle that problem though.

There’s also been some discussion in this forum about display differences depending on whether a placeable has collision meshes or not, although I couldn’t give a specific example.


#40

Flickering from same plane poly is particularly annoying for hairs : some parts need an ‘interior’, for example a lock of hair that can be seen from left and from right of the creature . The turnaround I have found is to have the interior face moved a bit from the ‘exterior’, but it’s a pain to work on such meshes.

It would be cool if the engine could support 2-sided textures