freneticllc / freneticgameengine Goto Github PK

The project could not be analyzed because of maven build errors. Please review the error messages here. Another build will be scheduled within 24 hours. If the build is successful this issue will be closed, otherwise the error message will be updated.

_{This is an automated GitHub Issue created by Sonatype DepShield. GitHub Apps, including DepShield, can be managed from the Developer settings of the repository administrators.}

I had an odd idea...

What if instead of building a shadow map for sky lighting, we calculated the shadow from each object into a massive array of relatively low-res* shadow images, and merely projected that down onto land?

* Current shadow map is generally pretty big, 1024x1024 x light source count is standard.
We could easily make this 64x64 without anyone complaining... But large objects would drop quality.
Perhaps a giant 2d texture atlas as opposed to a 3D texture, thus allowing dynamic refitting? Would require more involved shader uniforms to pass the correct data in...

Using some trickery*, this could even allow transparent objects to cast full accurate shadows!

* Trickery would basically just be a second buffer alongside the first that identifies rough alpha value of each shadow pixel.

This would probably not be particularly efficient compared to standard shadow mapping, but might be worth a try?

Alternately, could be used for ONLY transparent shadows and NOT for opaques?

Renderable models should load asynchronously.
Collision / internal model data should be able to load asynchronously.

Probably this would function as an "empty" VBO / collision mesh, that can be used fine, but is later substituted in with the real model once loaded.

This would function with callbacks and such.

Server data should just refuse to handle a model until it's loaded (EG spawn a plane, plane just isn't there until the plane's model is loaded...)

Lights should indicate what layers they cast shadow on (based on an object's Z coordinate, or a custom layer note?)
So EG a background light would cast shadows on background stuff, and light everything (Even in foreground) it reaches.
A foreground light would cast shadows on everything, and light everything it reaches.

So there's something I think some high end engines might do (I saw effects that might be this in GTAV)...

What if LOD'd objects, instead of or in addition to having some cheap one-off set of textures to apply,
had a sprite-ish prerender from the player's view, updated once per (given number of frames, or real-time duration).

This would involve:

• A texture for every model to placeholder it (can be fairly small) (Possibly in an array for mass-rendering?)
• A spriting system of some form (Possibly mass-rendered if possible)
• A significant update detector, probably with a minimum time duration (Player moves relative to object, or object moves relative to player...)
• A system to determine what LOD mode to use in any given situation (cross-trick LOD (what we already use), this new system, or no LOD effects)

• 2D Circle
• 3D Sphere
• 3D Cylinder

It should be possible to clip a model along some arbitrary bounding plane or set of planes, GPU-side.

I think this would be super handy for some special effects. (EG clip off a player's head for rendering first person view)

In deferred mode, point lights without shadows seem to render very oddly, with light not accurately placing on the world around them... needs fixing!

In deferred render mode*, we have easy room to add multiple-pass light additions.
This means we can have theoretically unlimited light sources per frame.
However, we don't currently do that. Why? Efficiency. Achieving higher limits than the built-in is slow.
How can we cheat it in anyway? Multiple runs of the shadow and light-add passes.
One run for each light, or one run each set of lights. Currently we do one run for ALL lights, but we could easily make that add additional passes if the present 'hard' limit is reached.

* Technically we can apply this to forward mode as well, with a slight bit more difficulty...

I think if nothing else it's worth having as an internal option, just in case it comes in handy later.

This will also allow less usage or disabling of the "low quality" shadow map logic (The system by which only 1/4th of the shadow map image is used instead of the whole one to allow room for more) if we choose to enable this feature described above.

#3 is relevant to shadow excessiveness as well.

Audio enforcer produces weird audio (glitched static and such), needs to be fixed.

Need a way to represent and render static world meshes.
They'd render in one single call-to-GPU (as opposed to one per shape).
If more than one texture is used, they should combine all textures into a reference atlas
(Probably with easy methods to share the atlas between different property instances, esp. for ones with similar texture sets)

This would be used to accelerate static world rendering.

Would need an easy init/destroy set for EG level changes, or world geometry updates.

Would be nice to have a utility to take a set of models and their position/scale/orientation, and convert them to a single property data set for use with the above.

It should be more reasonably doable to inject custom shaders into the engine.
In particular, maintain a list of custom shaders for the primary stages and a mapping of their requirements?
Primary stages being: FORWARD/SOLID, FORWARD/TRANSPARENT, DEFERRED/SOLID, and DEFERRED/TRANSPARENT
The rest probably don't need custom injection so much? But also be open to having that option available maybe (separate/future issue?)

My idea is the shaders would be registered with a map of required data, be easily attached to standard Renderable properties, ...
Also they would be carefully crafted as to PARTIAL shader definitions, not writing the entire fragment or vertex main call, but rather a sub-function call or direct injection that allows defining values separately from the logic for EG wrapping data, inputs, or special required effects - such as light/shadow application in the FORWARD shaders. Would be disableable by booleans set in-shader
IE, might look like this in a FORWARD shader:

// Top of file
#define FGE_LIGHTS_ENABLE 1
// Main defs and logic
#inject forward_inclusions
// Start of injection area
#define FGE_LIGHTS_ENABLE myVariableHere
// End of injection area
// Additional logic
#if FGE_LIGHTS_ENABLE
// Lighting logic
#endif
// Rest of file

Basically: the define could either be a static 1 or 0, OR it could be a variable name which will parse fine by later code? not sure.

That code would also have easy access to whatever variables it requests and maps...

Should be an easy way to configure shadows to just not calculate for a light.
As in, not at all, just blank to max depth or don't even calculate for that object!

Models should be able to take multiple animations, which are piled on top of each other.
A leg animation would naturally only animate legs still and all, so we can easily autocombine animations without caring for bone restrictions.

There's currently PropertyHolder.GetAllSubTypes: there should be a method to get the first match (Named like PropertyHolder.GetFirstSubType), or null.
Similar methods added wherever as need too.

Need to set up logical limits to SSR so that it "fades in" and out when approaching angles and distances it's likely to fail at.

Need some form of system to determine which fragments will have valid SSR and which won't, probably based on angles and such.

Probably could also stand to improve it in general, the look of the effect.

(SSR = Screen Space Reflection effects)