Porting ogre addns for Ogre 2.1

[Kohedlo]

There i see looks some difficult for porting hydrax, skyx and caeleum, galaxy engine, hikari, editable terrain- on Ogre tindalos.

i begins works on it.

[Herb]

That would be great. But, you listed a lot of addons there... Might start focusing on one. A new terrain system is coming for 2.1 (not sure if editable or not), and caeleum I'm not sure is worth the work with SkyX out. SkyX and Hydrax would be great to see under 2.1 support, but I don't think it will be an easy task.

[Kohedlo]

ok. Target is only HYDRAX.

[dark_sylinc]

Those interested in a sneak peak of the terrain can now do so at the 2.1-pso branch: https://bitbucket.org/sinbad/ogre/src/b ... t=v2-1-pso

Note that this terrain sample is still very WIP, only works with GL3+ at the moment.

As for the question if it's editable: The terrain pulls its data from a heightmap texture in the shaders, so updating the heightmap automatically updates the height of the terrain in realtime without any performance hit. Normals could be triggered to be computed again which only takes a couple milliseconds since it's done in an offscreen pixel shader.
Terrain shadows are not 100% done yet, but the compute shader takes less than a millisecond to generate it, so that won't be a problem.
Terrain splatting (i.e. which detail textures get blended together) are also pulled from a texture, thus updating the texture automatically updates the splats.

Long story short: those who want to edit the terrain should be able to do so with little problem. At the moment there is no interface to do so, but it shouldn't be hard at all.

[xrgo]

Sounds fantastic! I will test it another day, too busy now... meanwhile.. I can haz screenshot?

[SolarPortal]

Thanks, i will be checking this out very soon!

[dark_sylinc]

I can't take a screenshot right now where I am, and don't worry. It's nothing eye candy as those are all debug textures. You're not missing anything.

[c6burns]

Honestly it would be easier to just write a new water library from scratch than port hydrax to 2.1 IMHO. If you have any intensive wave/water rendering to do you have your work cut out with hydrax anyway. For example, hydrax has literally zero parallelization and operates almost entirely on the CPU. It also has it's own hand rolled material system to which everything is painfully tied. Lastly, the code is LGPL without a static link exception

[Kohedlo]

after integration i show new wip secreens!

[Kohedlo]

where find this joy- include class TERRA.H ?

[dermont]

Those interested in a sneak peak of the terrain can now do so at the 2.1-pso branch: https://bitbucket.org/sinbad/ogre/src/b ... t=v2-1-pso

Note that this terrain sample is still very WIP, only works with GL3+ at the moment.

As for the question if it's editable: The terrain pulls its data from a heightmap texture in the shaders, so updating the heightmap automatically updates the height of the terrain in realtime without any performance hit. Normals could be triggered to be computed again which only takes a couple milliseconds since it's done in an offscreen pixel shader.
Terrain shadows are not 100% done yet, but the compute shader takes less than a millisecond to generate it, so that won't be a problem.
Terrain splatting (i.e. which detail textures get blended together) are also pulled from a texture, thus updating the texture automatically updates the splats.

Long story short: those who want to edit the terrain should be able to do so with little problem. At the moment there is no interface to do so, but it shouldn't be hard at all.

Nice, I ran into a couple of problems running on a NVidia card:

Code: Select all

GLSL compile log: 0TerraShadowGenerator
0(89) : error C7011: implicit cast from "int" to "bool"

TerraShadowGenerator.glsl
//f( isSteep )
if( isSteep==1 )

GLSL compile log: 3758096384VertexShader_vs
0(116) : error C7011: implicit cast from "int" to "uint"
0(122) : error C7011: implicit cast from "ivec2" to "uvec2"

CrossPlatformSettings_piece_all.glsl
#extension GL_EXT_shader_implicit_conversions: require

[dark_sylinc]

Thanks. Fixed.
NVIDIA is very picky about type conversions and that drives me crazy.

where find this joy- include class TERRA.H ?

Umm in the Terra folder??
Not sure what you mean. All of the C++ code is self contained in the sample's directory. The sample itself says in the help (press F1) where the data files are located):

Code: Select all

"This sample depends on the media files:\n"
        "   * Samples/Media/2.0/scripts/Compositors/Tutorial_Terrain.compositor\n"
        "   * Samples/Media/2.0/materials/Tutorial_Terrain/*.*\n"
        "   * Samples/Media/Hlms/Terra/*.*\n"

Beware Terra is a work in progress. May contain bugs, may change its interface (particularly the JSON interface; the rest of the C++ is likely to stay very stable). There's also a perf. improvement I want to do. If the 4 roughness and 4 metalness of each splat are of the same resolution, I can batch them into two RGBA8888 textures (one for the roughness, one for the metalness) instead of eight R8 textures (which should result in better shader performance).

[dermont]

Thanks. Fixed.
NVIDIA is very picky about type conversions and that drives me crazy.

Another couple in VertexShader_vs.glsl, runs as is after those are fixed.

Code: Select all

	//Now shift X position for the left & right skirts
Line 83	####uVertexPos.x = max( int(uVertexPos.x) - 1, 0 );
	uVertexPos.x = uint(max( int(uVertexPos.x) - 1, 0 ));

	//Now shift Y position for the front & back skirts
Line 91	#####uVertexPos.y = max( int(uVertexPos.y) - 1, 0 );
	uVertexPos.y = uint(max( int(uVertexPos.y) - 1, 0 ));

[Kohedlo]

lets make tea and just do this. (integration)

[Kohedlo]

i try update new ogre but have debug linking errors:

1>Linking...
1> Creating library ..\lib\Debug\OgreMain_d.lib and object ..\lib\Debug\OgreMain_d.exp
1>OgreSceneManager.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall Ogre::TagPoint::updateFromParentImpl(void)" (?updateFromParentImpl@TagPoint@Ogre@@MAEXXZ)
1>OgreBone.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall Ogre::TagPoint::updateFromParentImpl(void)" (?updateFromParentImpl@TagPoint@Ogre@@MAEXXZ)
1>OgreSceneManager.obj : error LNK2001: unresolved external symbol "public: virtual class Ogre::TagPoint * __thiscall Ogre::TagPoint::createChildTagPoint(class Ogre::Vector3 const &,class Ogre::Quaternion const &)" (?createChildTagPoint@TagPoint@Ogre@@UAEPAV12@ABVVector3@2@ABVQuaternion@2@@Z)
1>OgreBone.obj : error LNK2001: unresolved external symbol "public: virtual class Ogre::TagPoint * __thiscall Ogre::TagPoint::createChildTagPoint(class Ogre::Vector3 const &,class Ogre::Quaternion const &)" (?createChildTagPoint@TagPoint@Ogre@@UAEPAV12@ABVVector3@2@ABVQuaternion@2@@Z)
1>OgreSceneManager.obj : error LNK2019: unresolved external symbol "public: virtual __thiscall Ogre::TagPoint::~TagPoint(void)" (??1TagPoint@Ogre@@UAE@XZ) referenced in function "public: virtual void * __thiscall Ogre::TagPoint::`scalar deleting destructor'(unsigned int)" (??_GTagPoint@Ogre@@UAEPAXI@Z)
1>OgreBone.obj : error LNK2001: unresolved external symbol "public: virtual __thiscall Ogre::TagPoint::~TagPoint(void)" (??1TagPoint@Ogre@@UAE@XZ)
1>OgreSceneManager.obj : error LNK2019: unresolved external symbol "public: __thiscall Ogre::TagPoint::TagPoint(unsigned int,class Ogre::SceneManager *,class Ogre::NodeMemoryManager *,class Ogre::SceneNode *)" (??0TagPoint@Ogre@@QAE@IPAVSceneManager@1@PAVNodeMemoryManager@1@PAVSceneNode@1@@Z) referenced in function "public: virtual class Ogre::TagPoint * __thiscall Ogre::SceneManager::createTagPointImpl(class Ogre::SceneNode *,class Ogre::NodeMemoryManager *)" (?createTagPointImpl@SceneManager@Ogre@@UAEPAVTagPoint@2@PAVSceneNode@2@PAVNodeMemoryManager@2@@Z)
1>OgreSceneManager.obj : error LNK2019: unresolved external symbol "public: static void __cdecl Ogre::TagPoint::updateAllTransformsBoneToTag(unsigned int,struct Ogre::Transform)" (?updateAllTransformsBoneToTag@TagPoint@Ogre@@SAXIUTransform@2@@Z) referenced in function "public: void __thiscall Ogre::SceneManager::updateAllTransformsBoneToTagThread(struct Ogre::UpdateTransformRequest const &,unsigned int)" (?updateAllTransformsBoneToTagThread@SceneManager@Ogre@@QAEXABUUpdateTransformRequest@2@I@Z)
1>OgreSceneManager.obj : error LNK2019: unresolved external symbol "public: static void __cdecl Ogre::TagPoint::updateAllTransformsTagOnTag(unsigned int,struct Ogre::Transform)" (?updateAllTransformsTagOnTag@TagPoint@Ogre@@SAXIUTransform@2@@Z) referenced in function "public: void __thiscall Ogre::SceneManager::updateAllTransformsTagOnTagThread(struct Ogre::UpdateTransformRequest const &,unsigned int)" (?updateAllTransformsTagOnTagThread@SceneManager@Ogre@@QAEXABUUpdateTransformRequest@2@I@Z)
1>OgreBone.obj : error LNK2019: unresolved external symbol "public: void __thiscall Ogre::TagPoint::_unsetParentBone(void)" (?_unsetParentBone@TagPoint@Ogre@@QAEXXZ) referenced in function "public: void __thiscall Ogre::Bone::_deinitialize(bool)" (?_deinitialize@Bone@Ogre@@QAEX_N@Z)
1>OgreBone.obj : error LNK2019: unresolved external symbol "public: void __thiscall Ogre::TagPoint::_setParentBone(class Ogre::Bone *)" (?_setParentBone@TagPoint@Ogre@@QAEXPAVBone@2@@Z) referenced in function "public: void __thiscall Ogre::Bone::addTagPoint(class Ogre::TagPoint *)" (?addTagPoint@Bone@Ogre@@QAEXPAVTagPoint@2@@Z)
1>..\..\..\..\..\..\..\Binaries\Debug\OgreMain_d.dll : fatal error LNK1120: 8 unresolved externals
1>Build log was saved at "file://d:\Imperial\IGE\2.5\IGE\Development\Temp\OgreMain.dir\Debug\BuildLog.htm"
1>0_GRAPHICS_0_OgreMain - 12 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

this present new TagPoint class, but give errors.

[dark_sylinc]

Sounds like you need to run CMake again and do a clean build.

These errors could only happen if OgreMain/src/Animation/OgreTagPoint.cpp was not included in the compilation, and this file is certainly present in the repository.

[Kohedlo]

perfectly true. need recmake. after posting topic come flashes of ideas that help fix problems. even if no answers.

[frostbyte]

mmm...i think c6burns is sort of right...the same apply for skyx...as much as i adore this eye-candys...
both are not very suitable for ogre2.1 since they are cpu-bounded and will cripple any fps gained by using 2.1...
they are also not suitale for mobile performance and the licence is an unattractive lgpl( i actualy prefer commercial licence... )
they also contain some bugs/artifacts that havn't been resolved till this day...cealum looks nice and light but i see now is also lgpl )-:
not sure though if it will be easier to write new plugins( who has the time for coding adventures this days? )
if we want new plugins suitable for 2.1 maybe we should consider( for real ) having an ogre2.1 addons bounty kick-starter....
or just wait...( sorry, i wish i had the time for a rewrite...but i don't )

mean-while... thank you dark-sylinc for making us kids believe that santa exist( and working on ogre 2.1 (-: )

[Kohedlo]

after updating Ogre 2.1 this week i catch problem with shaders:



there is shader:https://drive.google.com/file/d/0B-mxhq ... sp=sharing

shaders (glsl) was updated according to new ogre commit download.

[dark_sylinc]

Wow that is a really broken shader gen.

• Did you update your Hlms data folder? (in case you're copy pasting from the repository into your own location)
• What revision were you working before that was right? Please send the commit hash. The revision number from mercurial is useless. Isolating when it broke is extremely important.
• Do you know if a particular material setting is causing it?

Thanks.

[Kohedlo]

Hashes according Bitbucket:

this is "sinbad-ogre-895caebb3b01" package -downloading of PSO branch last week. Looks like as PBs glsl.

HLMS data folder was completly updated according the commit.

before i using fine:

sinbad-ogre-01ce8256a1e8 from 16.12.2015

and

sinbad-ogre-4776f170203b from 5.3.2016

let i feend details where this occours.

ImperialMaterial usess Ogre Datablocks with off unussed samplers by:

Code: Select all

datablock8->setTexture( Ogre::PBSM_DETAIL0_NM, NULL, Ogre::TexturePtr() );

[dark_sylinc]

Thanks.

I'm taking a look and you're running into quite an impossible scenario. DetailMaps_piece_ps.glsl defines:

Code: Select all

@property( detail_maps_normal )
	@add( second_valid_detail_map_nm, first_valid_detail_map_nm, 1 )
@end @property( !detail_maps_normal )
	@set( second_valid_detail_map_nm, 0 )
@end

Meaning second_valid_detail_map_nm must be between 0 and 4, and it's always defined. However the Hlms parser is complaining second_valid_detail_map_nm was not defined.
The only way I can see that's possible is if DetailMaps_piece_ps.glsl is not getting parsed correctly; which would happen if the file wasn't copied correctly or the Hlms paths are set incorrectly.

You may want to add:
In OgreHlms.cpp line 1636

Code: Select all

printf( "Processing %s\n", filename );
//Generate the shader file.
DataStreamPtr inFile = mDataFolder->open( filename.c_str() );

and in OgreHlms.cpp line 1554:

Code: Select all

DataStreamPtr inFile = archive->open(*itor);
printf( "Processing %s\n", itor->c_str() );

To see what's getting parsed in detail. That could help spotting path setup problems.

[Kohedlo]

first check have result NULL NULL

after deleting subdirectories in zip archives with HMLS data (pbs and unlit , without common)

result is:



after removing subdirectories in "common" hmls data folder archive is compilation move nice but still NULL FOR line check 1636 that at end lead to CRASH




first think- is new ogre commit DONT SEE SUBDIRS in archives.



OgreHMLS.cpp at line 1617 have checker :

Code: Select all

if( mDataFolder->exists( filename ) )

that is NULL is exists.
But in teal exsists normal path shader.

[Kohedlo]

after fixed NULL crash still...




except this- all ready for testing and seeng new terrain scrinshots)

[Kohedlo]

rolling back old HLMS data files (pre PSO) have no result with pso ogre build


and some question-

how to load- GpuNormalMapper_ps.glsl? as new = Ogre:: Terra(1 (terra, or common 2) argument?