jmonkeyengine / jmonkeyengine Goto Github PK

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=292

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=194

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=444

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=423

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=392

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=204

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=327

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=381

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=382

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=366

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=320

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=229

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=215

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=221

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=353

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=273

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=346

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=318

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=398

All shaders that are applied to in-game objects will require this
functionality. It should be possible, through a general shader API or a
specific define, to provide this functionality to any shader willing to use
it.
Example:
gl_FragCoord = APPLY_FOG(color);

where APPLY_FOG would be a define that either returns the provided color
(if fog is disabled) or apply the fogging.

How is this information going to be exposed to an arbitrary shader?
One solution is to define UserWorldParameters inside the material which would specify
what kind of user globals the shader can take. The world uniform updater checks which
are exposed in the system and if there are any matches between the material and
exposed vars then they are sent as uniforms.

How will these globals be exposed and what classes are allowed to expose them?
The class responsible for assigning these globals to the materials will contain them
and accept requests from user code to add them to the list. Classes like
SceneProcessor should be allowed to set them. Singlepass shadow-supporting shaders
will accept ug_ShadowMap[] for example, ShadowSceneProcesor generates shadow maps for
scene and exposes ug_ShadowMap[].

What about fog?
This is a fixed-pipeline state that is stored inside RenderState. How will the user
specify fog? In the Material definition, RenderState ONLY contains whether the
material should be fogged or not. No other fog-related state is allowed to be set
inside the material. There must be a way to set the other fog-state through the
Renderer since it may or may not be using fixed-pipeline. Renderers only supporting
shaders will set the g_FogParams and g_FogColor depending on the params the user
specified. While Renderers only supporting fixed-pipeline will set these parameters
using glFog and such and achieve the same result.
Reformulation: Material techniques that use shaders must expose g_FogParams and
g_FogColor, while Material techniques that do not use shaders must specify Fog Off
inside the RenderState block to disable fogging for the material.

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=64

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=383

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=234

The Renderer class and implementations are becoming more bloated. Since
jME3 does not have RenderStates to encapsulate specific functionality, it
is required to split the renderer into several "modules" which would handle
a specific functionality.

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=53

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=411

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=343

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=344

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=212

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=319

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=359

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=136

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=198

The installer of jMonkeyEngine SDK Alpha-2 fails to run on MacOSX 10.5 because it falsely tries to use Java 1.5 to start the installed.

Workaround:
If you have Java 1.6 installed on your computer you can temporarily rename the Java 1.5 folder in /System/Library/Frameworks/JavaVM.framework/Versions/ to some other name like "1.5backup" and run the installer. After installing the folder can be renamed back to "1.5".

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=272

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=35

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=405

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=438

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=401

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=431

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=146

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=413

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=338

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=387

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=291

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=388

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=131

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=384

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=241

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=445

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=313

Multithreading is an important issue right now. Taking advantage of it in
jME3 is critical. Some areas where multithreading can be used:

• Skeleton animation, mesh skinning
• Particle update
• Physics
• Networking
• Input polling
• OGG/Audio streaming
• Resource loading
• Terrain streaming

The details on how to implement these areas using multithreading will be
specified later.

Some parts of jME3 are already multi-threaded:

Physics runs in a parallel thread.
Networking runs in a parallel thread.
Audio and OGG streaming is done on a parallel thread.
Terrain streaming/LOD is done in a parallel thread.

jME3 is still missing asset loading on a separate thread, which can be critical if the application loads assets dynamically.

The AssetManager is the last part of jME3 that needs to take advantage of multithreading.

Reference on googlecode: https://code.google.com/p/jmonkeyengine/issues/detail?id=94