Few serious questions for Ogre-Next, moving Stunt Rally

[Crystal Hammer]

Hello. It's been probably years since I posted anything bigger, if at all.
Just upfront, we developed StuntRally, using finally Ogre 1.9, and own shader generator shiny (which was a joy to use).
So I will list a few questions, mostly about components (which in 2007 to 2010 where simply available and active, so I decided to use Ogre then).
Apologies if I don't go into each topic that has [2.1] or something or build and check if it works etc. I'll just assume if it's not [2.3], then it doesn't work for 2.3.
I simply would like answers gathered in 1 place, about what components are definitely working for Ogre 2.3, ready to use or with small fixes (i.e. not just Ogre 2.3 features list).

So my qestions are:

1. Are there any Ogre 2.x (best 2.3) bigger, open source projects, not just demos or samples or single components?
   Something using with many components at once and sort of a toolchain? E.g. with Gui, a 3D scene, maybe terrain etc.

2. Is MyGui working with Ogre 2.3?
   There were few Gui systems to choose from, MyGui was active and quite mature, also has lots of Gui controls.
   Biggest advantage for me and SR now, is that SR and its map/track editor use MyGui. So using anything else now would mean lots of changes.

3. Is Particle Universe working in Ogre 2.3?
   Particle system is and was in Ogre 1.x, simply working. Maybe not best, but ready to use.

4. I saw Terrain Sample in Ogre 2.3 and it's very good to have. I'm guessing it won't be too much to adapt for SR. But I have my own blendmap with noise and layers blending, also triplanar is optional (for 1 or 2 layers).

5. There is no vegetation plugin for models (trees, rocks) that have impostors.
   I guess since HW instancing is there, and I saw LOD demo too, it should be much better now.
   But what about impostors? PagedGeometry had much of code devoted to generating those. I don't think we would get away without using impostors for dense far vegetation right? I bet porting that PagedGeometry code for impostors isn't an easy task.

6. No plugin or demo for grass. I'm sure for someone skilled it's not much work to code. But any such case means much more work and time when porting SR (I'm just one person and a game developer, not a graphics engine or plugin creator/developer, although I did road myself).

7. Materials. I see that there is HLMS and a lot of documentation for it too.
   Any idea how different will it be to use it, compared to shiny in Ogre 1.x?
   For example: we have own code for fog (it has 2 colors blend, height based too, and inside water). I don't see a demo for fog. Would doing all of this in Ogre 2.3 be easy? Fog has to work on all shaders/materials except only Gui. I also did a scenery with negative (blackening) sun, I guess that'd be possible in 2.3 too?

8. How difficult would it be to create water, fluids and their shaders? I don't see a demo for it either. Just for info, we had flat fluid surfaces, box areas in many places, with reflection, refraction. And a great shader code, likely not following optics, e.g. animated (not textured) for mud and lava.

9. How is the export plugin / toolchain from Blender (sorry won't consider anything else here)?
   And how easy would it be to use Ogre 1.9 meshes in Ogre 2.3. Is it just a matter of running upgrader tool or even just loading them in code? I'd like to use Ogre 2.3 advantages of Mesh v2 here.

10. Is anyone in position to estimate how much time (for 1 person) would be to port StuntRally to Ogre 2.3? Mind you I have also a fulltime job and many small projects (on my website). I'm guessing it would good if this port even ended in a year, am I far off?

11. Off-topic, but why isn't there a WYSIWYG editor for posts on forum

Thank you for your time for anyone answering.

[dark_sylinc]

So I will list a few questions, mostly about components (which in 2007 to 2010 where simply available and active, so I decided to use Ogre then).

11. Off-topic, but why isn't there a WYSIWYG editor for posts on forum

2006-2010 was golden era for Ogre, thus there was a lot more active projects and tools that you see now.

We lost a lot of users to (back then) recently-made-cheap engines likes Unity and UE4. Fortunately Godot appeared as a FOSS game engine alternative, since Ogre is actually a rendering engine.

Our userbase shifted from gaming to:

• Users who need a rendering engine, not a game engine
• Users that need FOSS as a requirement for whatever reason
• Users where Unity/UE4/etc license is a problem
• Users who need a lot of customization
• Users who need to tune performance to a level they can't with the other engines
• Users who are more comfortable with our engine

Btw be sure to checkout Hlms Editor for a WYSIWYG editor

1. Are there any Ogre 2.x (best 2.3) bigger, open source projects, not just demos or samples or single components?
Something using with many components at once and sort of a toolchain? E.g. with Gui, a 3D scene, maybe terrain etc.

Ignition meets all that criteria. It supports both ogre and ogre-next.

2. Is MyGui working with Ogre 2.3?
There were few Gui systems to choose from, MyGui was active and quite mature, also has lots of Gui controls.
Biggest advantage for me and SR now, is that SR and its map/track editor use MyGui. So using anything else now would mean lots of changes.

There were these posts.

Perhaps other users know more.

3. Is Particle Universe working in Ogre 2.3?
Particle system is and was in Ogre 1.x, simply working. Maybe not best, but ready to use.

I don't recal PU working with Ogre-Next, but PU, like the old ParticleFX plugin, relied on systems that should still be supported but would probably require adding the v1 namespace and fixing a few virtual listeners that changed their argument signature.

Most likely change is that we now add renderables to screen by adding them to MovableObject::mRenderables instead of returning them in MovableObject::visitRenderables()

It should be relatively easy to port

4. I saw Terrain Sample in Ogre 2.3 and it's very good to have. I'm guessing it won't be too much to adapt for SR. But I have my own blendmap with noise and layers blending, also triplanar is optional (for 1 or 2 layers).

Yes, our terrain comes as a sample rather than a component because everyone has their own needs on how rendering should be customized

5. There is no vegetation plugin for models (trees, rocks) that have impostors.
I guess since HW instancing is there, and I saw LOD demo too, it should be much better now.
But what about impostors? PagedGeometry had much of code devoted to generating those. I don't think we would get away without using impostors for dense far vegetation right? I bet porting that PagedGeometry code for impostors isn't an easy task.

6. No plugin or demo for grass. I'm sure for someone skilled it's not much work to code. But any such case means much more work and time when porting SR (I'm just one person and a game developer, not a graphics engine or plugin creator/developer, although I did road myself).

These two have been in my backburner for a long time but I haven't had the time to implement them yet. Neither of them are particularly difficult as you said but it requires time and our users haven't demanded it yet or implemented their own.

I don't think we would get away without using impostors for dense far vegetation right?

Actually I think you might. GPUs are very fast nowadays and as long as you keep a good vertex per batch ratio and take advantage of LOD, it may just work.

7. Materials. I see that there is HLMS and a lot of documentation for it too.
Any idea how different will it be to use it, compared to shiny in Ogre 1.x?

Be sure to look at the FAQ too!
Particularly "I'm writing my own Hlms implementation, or just want to know more about it. Where do I find learning material/resources?" question

8. How difficult would it be to create water, fluids and their shaders? I don't see a demo for it either. Just for info, we had flat fluid surfaces, box areas in many places, with reflection, refraction. And a great shader code, likely not following optics, e.g. animated (not textured) for mud and lava.

xrgo modified the Terrain Hlms and turned it into ocean.
Adapting it to 2.3 requires only a few tweaks.

9. How is the export plugin / toolchain from Blender (sorry won't consider anything else here)?
And how easy would it be to use Ogre 1.9 meshes in Ogre 2.3. Is it just a matter of running upgrader tool or even just loading them in code? I'd like to use Ogre 2.3 advantages of Mesh v2 here.

XMLConverter has been renamed to MeshTool. MeshTool supports converting between 1.10 and older formats back and forth to 2.x; and the XML format remains the same.

As such most of the DDC tools that work for Ogre work for Ogre-Next too.

10. Is anyone in position to estimate how much time (for 1 person) would be to port StuntRally to Ogre 2.3?

First port it to 2.1; which is more similar to 1.x; then to 2.3
As for the time, I don't know how complex StuntRally is; but several users have ported their complex projects and have taken anywhere between 1-6 months aprox.

You may want to try porting a small scale project first, to get at sense of the work involved.

Cheers

[paroj]

well, the points you raise are actually the reason why Ogre1 is still maintained: "Aint nobody got time to rewrite those things."
See: https://www.ogre3d.org/about/what-version-to-choose

2. MyGui status
3. PU: does not work. I thought ParticleFX would work though.
5 & 6. PG: does not work. Note, that its not only Impostors, but also paging and LOD fading that you lose here.
9. blender2ogre: geometry only. will invoke MeshTool, but only exports Ogre1 Materials
11. it is as old as Ogre

10. please define "port". What are you expecting to gain? Get SR looking the same as now, but running faster? Switch to PBR based materials?

[Crystal Hammer]

Thanks for answers.
Well, it still doesn't look too good to move to Ogre 2.3 with StuntRally now. If MyGui and PU or ParticleFX were already working fine that would be great and I'd probably start and try to deal with other things. Or even try other Gui if Particles and Vegetation were available.
Either way I think I'll start slowly with Ogre 2.3 with some basics and build up. At least checking if I could deal with other things (like HLMS and vegetation, fog, water etc).
Anyway what is the working / recommended Gui for Ogre 2.x now, is it colibrigui?

10. By "port" I mean yeah, fully transforming all SR features to Ogre 2.3. There is a lot, GUI is pretty extensive. Especially in editor (its latest screens and features are nicely presented here), which can edit all track and scene parameters (including my road from spline). And there are even many graphs for simulation and car editor in game shown here.
I'd expect SR gaining more Fps and better look with this port. I mean Ogre 2.3 has HDR, PBR materials (which I wan't to use since start), nice shadows etc. Since Ogre 2.3 can deal with 10000 objects per frame I think SR would greatly benefit in more dense and varying vegetation. In Ogre 1.x SR already slowed down after 500 batches per frame, and adding more trees or more kinds of vegetation just meant bigger CPU lags when PagedGeometry has to process all vertices on CPU for all.

[paroj]

regarding the looks, Ogre Next will certainly give you better lighting. It has global illumination, area lights and image based lighting.
PBR will be more tricky as you must update your asset pipeline for things to actually look better. Create normal maps, roughness maps etc.

When it comes to performance, Ogre Next will not allow you to use more batches. These are API imposed limits. What it does though, is automatically batch things for you and improves resource layout for batching like putting all images into the same texture and all geometry into the same hardware buffer.
You could achieve something similar with Ogre1 too, see:
https://ogrecave.github.io/ogre/api/lat ... ncing.html

Also note, that there were some improvements regarding shadows in Ogre1, too:
https://www.ogre3d.org/2020/07/26/ogre- ... er_shadows

Ideally you should create a standalone project where you just load a single track and a single car and skip everything else. This way you can judge the efforts without digging yourself deep into porting issues.

[Crystal Hammer]

Right. Yeah I guess something could be done to improve SR with previous Ogre. Years ago I saw Cascaded ShadowMaps demo, but didn't have the strength to adapt it.

Now I'm actually more into trying Ogre 2.3 and all the newest features, there are many of them.
I tried Terrain already and added basic fog. Still, terrain shader code looks like magic to me.

I got small questions:

• Any idea what is taking 5 seconds every time when Turorial_Terrain starts?
• How do I get current batches and triangles counts rendered? This was all I needed in Ogre 1 to have good idea, I can't even without them.

I've built colibrigui, it looks nice, but widgets are quite limited, pretty much the screeshot shows all. Not enough for SR.

Apropos 1, there is also:
https://gitlab.com/edherbert/southsea/
https://gitlab.com/edherbert/avEngine
https://avdocumentation.readthedocs.io/ ... ngine.html
based on Ogre 2.2 and using ImGui.
I gave it a try but it didn't build for me.

[TaaTT4]

• Any idea what is taking 5 seconds every time when Turorial_Terrain starts?

It could be the time taken to build the shaders (especially if you're using D3D11 render system where the compiler is a way more slower compared to GL one). Ensure the "Fast shader build hack" option is active in the config dialog (should be enabled by default, I believe) to reduce build time and save compiled shaders in cache (search how to do it in forum and/or in OGRE samples) to pay that slowdown just the first time you run the app.

I've built colibrigui, it looks nice, but widgets are quite limited, pretty much the screeshot shows all. Not enough for SR.

Integrating Dear ImGui rendering with OGRE is quite simple and straightforward (less than 200 lines of code). If you're interested, I can provide you the plugin I've created for my engine (it contains some references to some specific classes/objects of the engine, but you should be able to get the big picture nonetheless).

[Crystal Hammer]

Well I'm using GL3+, I'm on Debian. I've read that shader compile times on DX are insanely long now.
I was thinking of shaders in Terrain too, but this happens always, even if I don't change anything and start 2nd time when all cache files are present:
hlmsDiskCache1.bin, hlmsDiskCache3.bin, hlmsDiskCache7.bin, microcodeCodeCache.cache, textureMetadataCache.json, same folder where binary is.
And all other Ogre samples start in like 1-2 seconds.

Integrating Dear ImGui rendering with OGRE is quite simple and straightforward (less than 200 lines of code). If you're interested, I can provide you the plugin I've created for my engine (it contains some references to some specific classes/objects of the engine, but you should be able to get the big picture nonetheless).

That would be great. I hope this is OSS friendly and I could adapt it for Ogre 2.3 (GL and DX eventually). I also saw some topics about ImGui on forum. If this works I'm gonna consider moving to ImGui, it was awesome to use and code with it, just didn't have textures.

[dark_sylinc]

• Any idea what is taking 5 seconds every time when Turorial_Terrain starts?

My guess it could be Heightmap.png which is 1024x1024 R16 PNG being loaded. Try replacing it with a blank terrain of the same resolution which decompresses much faster.

Another reason could be compilation of the compute shaders for terrain shadows.

It really depends on your system specs (HW GPU vendor, driver version, and CPU speed). In my case I didn't even notice the terrain takes longer to load

• How do I get current batches and triangles counts rendered? This was all I needed in Ogre 1 to have good idea, I can't even without them.

Call RenderSystem::setMetricsRecordingEnabled( true ) and then see RenderSystem::getMetrics

[TaaTT4]

Integrating Dear ImGui rendering with OGRE is quite simple and straightforward (less than 200 lines of code). If you're interested, I can provide you the plugin I've created for my engine (it contains some references to some specific classes/objects of the engine, but you should be able to get the big picture nonetheless).

That would be great. I hope this is OSS friendly and I could adapt it for Ogre 2.3 (GL and DX eventually). I also saw some topics about ImGui on forum. If this works I'm gonna consider moving to ImGui, it was awesome to use and code with it, just didn't have textures.

Code: Select all

#pragma once


#include <NumenAppListener.h>
#include <NumenAppPlugin.h>
#include <NumenInputListener.h>

#include <OgreFrameListener.h>

#include "OgreImguiPrerequisites.h"


namespace OgreImgui
{
    class OGREIMGUI_DLL_IE Plugin :
        public Numen::AppListener,
        public Numen::AppPlugin,
        public Numen::InputListener,
        public Ogre::FrameListener
    {

public:

                                Plugin();
    virtual                     ~Plugin() = default;

    virtual void                onAppCleanup() override;
    virtual void                onAppEvent(const SDL_Event& event) override;
    virtual void                onAppStartup() override;

    virtual void                initialise() override;
    virtual void                shutdown() override;

    virtual bool                onKeyboardKeyDown(const SDL_KeyboardEvent& event) override;
    virtual bool                onKeyboardKeyUp(const SDL_KeyboardEvent& event) override;
    virtual bool                onMouseButtonDown(const SDL_MouseButtonEvent& event) override;
    virtual bool                onMouseButtonUp(const SDL_MouseButtonEvent& event) override;
    virtual bool                onMouseWheelMove(const SDL_MouseWheelEvent& event) override;
    virtual bool                onTextInput(const SDL_TextInputEvent& event) const override;

    virtual bool                frameRenderingQueued(const Ogre::FrameEvent& evt) override;
    virtual bool                frameStarted(const Ogre::FrameEvent& evt) override;

private:

    Ogre::RenderPassDescriptor* m_renderPass;

};
}

Code: Select all

#include "OgreImguiPlugin.h"

#include <imgui_impl_dx11.h>
#include <imgui_impl_sdl.h>

#include <NumenApp.h>
#include <NumenAppUtils.h>
#include <NumenInputManager.h>

#include <OgreRoot.h>
#include <OgreWindow.h>
#include <RenderSystems/Direct3D11/OgreD3D11RenderSystem.h>


using namespace ImGui;
using namespace Numen;
using namespace OgreImgui;




Plugin::Plugin() :
    AppPlugin{"OGRE Dear ImGui"},
    m_renderPass{nullptr}
{
}


void Plugin::onAppCleanup()
{
    Ogre::Root::getSingleton().getRenderSystem()->destroyRenderPassDescriptor(m_renderPass);

InputManager::getSingleton().removeListener(this);
}


void Plugin::onAppEvent(const SDL_Event& event)
{
    ImGui_ImplSDL2_ProcessEvent(&event);
}


void Plugin::onAppStartup()
{
    m_renderPass = Ogre::Root::getSingleton().getRenderSystem()->createRenderPassDescriptor();

m_renderPass->mColour[0].texture = AppUtils::app()->windowOgre()->getTexture();
m_renderPass->mColour[0].loadAction = Ogre::LoadAction::Load;
m_renderPass->mColour[0].storeAction = Ogre::StoreAction::Store;

m_renderPass->entriesModified(Ogre::RenderPassDescriptor::All);

InputManager::getSingleton().addListener(this, InputQueue::Debug);
}


void Plugin::initialise()
{
    IMGUI_CHECKVERSION();

CreateContext();

GetIO().ConfigFlags |= ImGuiConfigFlags_NavEnableKeyboard | ImGuiConfigFlags_DockingEnable;

auto& device = static_cast<Ogre::D3D11RenderSystem*>(Ogre::Root::getSingleton().getRenderSystem())->_getDevice();

ImGui_ImplSDL2_InitForD3D(AppUtils::app()->windowSdl());
ImGui_ImplDX11_Init(device.get(), device.GetImmediateContext());

AppUtils::app()->addListener(this);

Ogre::Root::getSingleton().addFrameListener(this);
}


void Plugin::shutdown()
{
    if (GetCurrentContext())
    {
        ImGui_ImplDX11_Shutdown();
        ImGui_ImplSDL2_Shutdown();

    DestroyContext();
}

AppUtils::app()->removeListener(this);

Ogre::Root::getSingleton().removeFrameListener(this);
}


bool Plugin::onKeyboardKeyDown(const SDL_KeyboardEvent& event)
{
    return GetIO().WantCaptureKeyboard;
}


bool Plugin::onKeyboardKeyUp(const SDL_KeyboardEvent& event)
{
    return GetIO().WantCaptureKeyboard;
}


bool Plugin::onMouseButtonDown(const SDL_MouseButtonEvent& event)
{
    return GetIO().WantCaptureMouse;
}


bool Plugin::onMouseButtonUp(const SDL_MouseButtonEvent& event)
{
    return GetIO().WantCaptureMouse;
}


bool Plugin::onMouseWheelMove(const SDL_MouseWheelEvent& event)
{
    return GetIO().WantCaptureMouse;
}


bool Plugin::onTextInput(const SDL_TextInputEvent& event) const
{
    return GetIO().WantCaptureKeyboard;
}


bool Plugin::frameRenderingQueued(const Ogre::FrameEvent& evt)
{
    Render();

const auto viewportSize = Ogre::Vector4{0.0f, 0.0f, 1.0f, 1.0f};

const auto rendersystem = Ogre::Root::getSingleton().getRenderSystem();
rendersystem->beginRenderPassDescriptor(m_renderPass, m_renderPass->mColour[0].texture, 0, &viewportSize, &viewportSize, 1, false, false);
rendersystem->executeRenderPassDescriptorDelayedActions();

ImGui_ImplDX11_RenderDrawData(GetDrawData());

rendersystem->endRenderPassDescriptor();

return true;
}


bool Plugin::frameStarted(const Ogre::FrameEvent& evt)
{
    ImGui_ImplSDL2_NewFrame();
    ImGui_ImplDX11_NewFrame();

NewFrame();

return true;
}

[Crystal Hammer]

Ok thanks. I see it's DX11 only right, but there was something similar for GL3. I'm gonna try MyGui first, after all I got a lot in it already.

It is the terrain compositor that delays me 5 seconds. No idea, maybe compute shaders could have its cache if they don't?
Adding return; just after { in void ShadowMapper::createCompositorWorkspace() makes it fast, just has garbage on terrain shadow, IDK even how to clear the texture .

So particles work, but I can't get anything else than white squares. I tried many different combinations of pbs parameters and no difference. Don't see anything in Ogre.log.
I've pushed some particles to my repo.
Anyway I see that they still need 1 batch (draw call) per emitter, so it's the same issue I had with them in Ogre 1.x that made me not use many.

[dark_sylinc]

Particles don't have normals, so they should use Unlit.

[Crystal Hammer]

Okay so:

Code: Select all

//  Particles  ---------------
hlms BoostRed unlit
{
	diffuse_map boost_red.png

Now I see texture, but I can't get alpha blending.
This works:

Code: Select all

	alpha_test greater 0.1
	use_alpha_from_textures true

but anything from below doesn't change, I have no alpha blending or add:

Code: Select all

	blend_operation add
	blend_operation_alpha add
	src_blend_factor one_minus_src_alpha
	dst_blend_factor one_minus_dst_alpha
	src_alpha_blend_factor one_minus_src_alpha
	dst_alpha_blend_factor one_minus_dst_alpha
}

[dark_sylinc]

The following should work:

Code: Select all

hlms BoostRed unlit
{
	diffuse_map boost_red.png
	depth_write	off
	scene_blend	alpha_blend
}

// Alternatively, additive blending
hlms BoostRed unlit
{
	diffuse_map boost_red.png
	depth_write	off
	scene_blend	add
}

[Crystal Hammer]

Ah okay it does, thank you. So it's that old syntax.

[Crystal Hammer]

Edit: I am currently facing only one major problem (not knowing how to fix or somewhat above my level):

• MyGui with Ogre 2.3 not starting post here.

So correct me if I'm wrong, apropos grass: given that it's been years, I think it's safe to say that there won't be any new sample/tutorial appearing soon?
Which makes grass not a medium but an advanced difficulty feature if someone has to develop it themself.
If so then could you write how would you implement grass?
I've looked at few random tutorials, and given that my experience with HLMS and geometry/tesselation/compute shaders is rather minimal (also no examples besides Terra), I'm kind of fuzzy. So I'm guessing we would use the terrain height map texture and either some grass density calculations or texture, what next? Do we need any mesh on CPU first? Geometry shader would add more grass blades / vertices?

I think I'd rather know this earlier than later, so let me add 3 new "bigger" questions here:

1. What kind of support can I expect? From developers which basically translates to Matias right.
   I understand that FOSS projects are at the end of queue after paid and commercial projects which you have to support too. But from what I saw and think: you usually don't leave problems/questions unanswered, right? Being also very busy, what would be a timeline or capacity, is there any or hard to say?

2. What is the best approach?
   E.g. for that glow issue, is it enough to post here and expect fixes or should I create an issue/ticket? Should I create separate topics for each 2.3 issue I'm facing? How do I know if or when to expect anything? E.g. if it's approved bug, being fixed etc.
   I'm guessing nobody will try fixing MyGUI. Seems like previous versions are working.

3. Documentation.
   I think I've read through the Ogre 2.0 Porting Manual DRAFT.odt twice and gone though Ogre 2.2 and Ogre 2.3 changes. It's kind of split/separate.
   In the end I think there is a noticable gap between what is in docs and what has to be learned from samples code (there is some description in each at least). Making it advanced difficulty again.

[Crystal Hammer]

Ok fixed fog issues.
Here's what I've learned apropos HLMS (so correct me if I'm wrong, this isn't documented anywhere is it?):
*.any files are just gathered in *.glsl or *hlsl etc in the end.
e.g. main() is in /Media/Hlms/Pbs/GLSL/VertexShader_vs.glsl and in /Media/Hlms/Pbs/GLSL/PixelShader_ps.glsl for GL.

At end of /Media/Hlms/Pbs/Any/Main/500.Structs_piece_vs_piece_ps.any
inside @piece( VStoPS_block ) there is @insertpiece( custom_VStoPS )
which can be defined in a new .any file and contain any extra variables to pass.
But what do I do if Terra already defines custom_VStoPS, I need to @undefpiece it and define again with my stuff added?

There also are many of such "@insertpiece( custom_" occurences allowing to modify current shaders.
I think the idea is to edit as much as possible in own files.

[Crystal Hammer]

Allright, I dropped my old fog attempts and I'm now using Atmosphere. Looks pretty.
I also added to my terrain demo project adjusting all of its parameters live.
Fog seems to be quite dense and bright, for low sun pitch angles. But whatever, I have rather wrong light in my demo. I'm using mSunLight->setPowerScale( Math::PI * 3 ); But with * 1 all is too dark. Is HDR needed or better material parameters?

Gallery here. I don't see that sticky post with screenshots.
I had some progress, post here with some stats.
Copied:

• 70 Fps with 3M triangles (faces) and 10k model instances visible (of 100k).
• 127 Fps with 1,7M triangles and 6400 instances.

Testing on Debian 11 with Radeon RX 570 and amdgpu drivers.
With only 15 draw calls, really? Amazing. I think I got like 6 to 8 LODs in all meshes. And I agree, no need for impostors this way.
I didn't think I'd see too dense vegetation with good, smooth Fps already on my GPU. Great.

I want to add dynamic reflections next, and also try that Ocean here too.
How should I add grass? I really have no idea. Terra has no vertex buffer? Is some new magic for me. Could it be used for grass too?
Another question. If I wanted to try HDR and add an option for it to users, and some shadow options too. How would I achieve this? Should I be creating workspaces and all from code, not from files? If I see this right, examples have setups in workspace files, but if I wanted it all together and also toggleable how should I best combine it?
I'm also missing triplanar, how difficult is it to add?

[dark_sylinc]

Fog seems to be quite dense and bright, for low sun pitch angles. But whatever, I have rather wrong light in my demo. I'm using mSunLight->setPowerScale( Math::PI * 3 ); But with * 1 all is too dark. Is HDR needed or better material parameters?

Using PI * 3 seems too much.

Perhaps the materials have a low diffuse or wrong fresnel params?

As for the atmo being too bright, you have full control over the preset in AtmosphereNpr, see AtmosphereNpr::sunPower, skyPower, densityCoeff and densityDiffusion. These setting affect how bright/dark the atmo will be.

With only 15 draw calls, really? Amazing. I think I got like 6 to 8 LODs in all meshes. And I agree, no need for impostors this way.
I didn't think I'd see too dense vegetation with good, smooth Fps already on my GPU. Great.

I want to add dynamic reflections next, and also try that Ocean here too.

xrgo contributed an Ocean shader by modifying Terra.

I never found the time to integrate it into OgreNext officially.

How should I add grass? I really have no idea. Terra has no vertex buffer? Is some new magic for me. Could it be used for grass too?

For grass blades in theory yes; as one could draw a grass blade in 2D; using returnBladeVertexHeight( vertexId % vertexPerBlade ) and then orient it in 3D (+ sample Terra's heightmap to obtain exactly at which height to position it). But I never got the time to play with it.

Still grass needs to be complimented with some more traditional LOD because rendering in the distance with grass blades is too much for GPUs.

Otherwise it can be rendered traditionally. It's best to generate "patches" of grass.

If the patches are too big; you can't take advantage of Ogre's frustum culling correctly. If the patches are too small, you get too much CPU usage per patch and the GPU also can't batch them efficiently either (not enough vertices per draw).

Another question. If I wanted to try HDR and add an option for it to users, and some shadow options too. How would I achieve this? Should I be creating workspaces and all from code, not from files? If I see this right, examples have setups in workspace files, but if I wanted it all together and also toggleable how should I best combine it?

Shadows is the easiest part. See Samples/2.0/ApiUsage/ShadowMapFromCode/ShadowMapFromCode.cpp and then have all your nodes reference the shadow node by name you will create in C++.

As for HDR toggle (or whatever you decide): Although you can create them from C++, IMO that's crazy. The amount of C++ code needed is a lot and there's a lot of details and it's difficult to see what is going on.

In my experience you should keep a set of Nodes in your compositor scripts that you glue together from C++ to generate the workspace (see Compositor sample) and if something requires customization, try seeing if you can use a CompositorWorkspaceListener instead of creating your own CompositorPassSceneDef/CompositorPassQuadDef.

Thus you'll have e.g. "RenderSceneHdrNode" and a "RenderSceneLdrNode", plus a "DepthOfFieldNode", plus a "SSAONode" and finally a "FinalCompositing" pass.

Thus your workspace definition uses either RenderSceneHdrNode or RenderSceneLdrNode; then uses the optional effects (DOF & SSAO) and finally outputs to FinalCompositing.

Thus the Workspace definition is driven mostly from C++ (either by creating it from scratch or modifying one you defined from script) while the nodes themselves are written in scripts; using the "identifier" keyword to identify individual passes in C++

I'm also missing triplanar, how difficult is it to add?

See viewtopic.php?p=539062

Cheers

[Crystal Hammer]

All right thanks for answers.
I got few more questions. I started with SR code and I am slowly restoring it's features in Ogre-Next.

• I made Terra not use image, but load from 32bit floats array, and so I use height (scale) 1.0, in Terra::load

  Code: Select all

  m_height = dimensions.y;

  Not sure if there is a bug with this or maybe I broke something, but now I get weird visibility issues as shown on video. Pages start to disappear when camera gets higher, and even depend on rotation, and also when I rotate very quickly.
  Something probably in

  Code: Select all

  bool Terra::isVisible

  because when I added

  Code: Select all

  return true;

  after //Outside there, I got rid of this bug (and likely of better performance too). So I guess you could replicate this with a 32bit heightmap (not just 0..1) in original code too.

• Could you please fix that bug in Terra, when no pages are visible it goes into infinite loop and I even get weird colors on screen and can't do anything. It made me reset my PC like 10 times yesterday and already 5 today . I think it's that:

  Code: Select all

  //TODO: When we're too far (outside the terrain), just display a 4x4 grid or something like that.
  

  I mean anything so it still works and doesn't freeze PC.
  Combined with that bug above, it's almost impossible to use.

• Can I do all from

  Code: Select all

  Media/materials/Tutorial_Terrain/Terra.material.json

  but from code? I mean dynamically before creating Terra.

• Why is terrain skirt so big? It's always reaching lowest height of terrain? I remember old terrain skirt was relative to surface and adjustable size. Was nice, I didn't need more.

• How can I make soft particles, is it easy?

• Does v1::RibbonTrail work? For me it crashes in

  Code: Select all

  mSceneMgr->createMovableObject("RibbonTrail", 0, &params);

• Does v1::BillboardSet work? Code seems okay but I get in .log:

  Code: Select all

  16:04:12: Can't assign material flare1 because this Material does not exist. Have you forgotten to define it in a .material script?
  

  even though I have

  Code: Select all

  hlms flare1 unlit
  {
      diffuse_map flare1.png
      depth_write	off
      scene_blend add
  }
  

• Is there an easy way to preload stuff so I don't get delays when stuff appears? It's like 0.3 sec for particles 0.5 sec for car or other models etc. Way too much for me.

• Does Empty project CMake work on Windows and Linux, after using scripts to build from sources?
  https://ogrecave.github.io/ogre-next/ap ... r_app.html
  https://github.com/OGRECave/ogre-next/t ... pts/output

• Is there an easy way to toggle wireframe for everything?

• How can we get used GPU RAM MB value?

[dark_sylinc]

All right thanks for answers.
I got few more questions. I started with SR code and I am slowly restoring it's features in Ogre-Next.

• I made Terra not use image, but load from 32bit floats array, and so I use height (scale) 1.0, in Terra::load

  Code: Select all

  m_height = dimensions.y;

  Not sure if there is a bug with this or maybe I broke something, but now I get weird visibility issues as shown on video. Pages start to disappear when camera gets higher, and even depend on rotation, and also when I rotate very quickly.
  Something probably in

  Code: Select all

  bool Terra::isVisible

  because when I added

  Code: Select all

  return true;

  after //Outside there, I got rid of this bug (and likely of better performance too). So I guess you could replicate this with a 32bit heightmap (not just 0..1) in original code too.

Terra was designed to work with normalized data (i.e. heightmap in range [0; 1]). Because your m_height = 1, we can't properly cull the tiles.

Since your heightmap is in 32 floats, a simple solution is to scale down the entire heightmap by the maximum value (or a very large value) to send everything in the range [0; 1] and set m_height to that value.

• Could you please fix that bug in Terra, when no pages are visible it goes into infinite loop and I even get weird colors on screen and can't do anything. It made me reset my PC like 10 times yesterday and already 5 today . I think it's that:

  Code: Select all

  //TODO: When we're too far (outside the terrain), just display a 4x4 grid or something like that.
  

  I mean anything so it still works and doesn't freeze PC.
  Combined with that bug above, it's almost impossible to use.

Say WHAT!? How can I repro that bug?

Btw if your PC hangs you can:

1. Quickly before you reach a point of no return: Ctrl+Alt+F2 then Ctrl + Alt + Supr to reboot the system (safely)

2. If you've another PC and yours has SSH server, login to your hang computer and type sudo service lightdm restart (or gdm3, or sddm or whatever your manager is)

• Can I do all from

  Code: Select all

  Media/materials/Tutorial_Terrain/Terra.material.json

  but from code? I mean dynamically before creating Terra.

Yes. Get HlmsTerra then call HlmsTerra::createDatablock and downcast it to HlmsTerraDatablock:

Code: Select all

Ogre::HlmsDatablock *datablock =
	hlms->createDatablock( datablockName.c_str(), datablockName.c_str(), Ogre::HlmsMacroblock(),
						   Ogre::HlmsBlendblock(), Ogre::HlmsParamVec() );
assert( dynamic_cast<Ogre::HlmsTerraDatablock *>( datablock ) );
Ogre::HlmsTerraDatablock *datablock = static_cast<Ogre::HlmsTerraDatablock *>( datablock );

- Why is terrain skirt so big? It's always reaching lowest height of terrain? I remember old terrain skirt was relative to surface and adjustable size. Was nice, I didn't need more.

We try to autocalculate it. You can override the value with Terra::setCustomSkirtMinHeight

- How can I make soft particles, is it easy?

For me yes... you'd have to be a bit more familiar with adding custom Hlms unlit pieces so you can sample from the depth buffer; and with the compositor to grab the depth buffer.

- Do v1::RibbonTrails work? For me it crashes in

Code: Select all

mSceneMgr->createMovableObject("RibbonTrail", 0, &params);

Does SceneManager::createRibbonTrail work? You are providing a nullptr as ObjectMemoryManager and that is not valid.

You can get one from SceneManager::_getEntityMemoryManager

- Does v1::BillboardSet work? Code seems okay but I get in .log:

Code: Select all

16:04:12: Can't assign material flare1 because this Material does not exist. Have you forgotten to define it in a .material script?

even though I have

Code: Select all

hlms flare1 unlit
{
    diffuse_map flare1.png
    depth_write	off
    scene_blend add
}

Check the log to see if the file is being parsed?

Another possibility is that you are calling Renderable::setMaterialName instead of Renderable::setDatablockOrMaterialName.
The former only works on low level materials. The latter will first try Hlms materials, then low level materials.

- Is there an easy way to preload stuff so I don't get delays when stuff appears? It's like 0.3 sec for particles 0.5 sec for car or other models etc. Way too much for me.

You can preload textures using HlmsDatablock::preload but I suspect you are having trouble with shader compile times.

Make sure you are using the HlmsDiskCache, the Microcode cache (see GraphicsSystem::loadHlmsDiskCache) and the texture cache (see GraphicsSystem::loadTextureCache).

Other than that, unfortunately currently our "best" solution is that you setup a scene that has one object of every shader you need (i.e. two material with different colours will use the same shader, one material with 1 diffuse texture while another uses 1 diffuse and 1 normal map will use different shaders) render it while having a black screen on top to cover it; and then destroy everything and continue with your game.

That way you will preload everything you need. It's a very dirty solution but it works.

• Does Empty project CMake work on Windows and Linux, after using scripts to build from sources?
  https://ogrecave.github.io/ogre-next/ap ... r_app.html
  https://github.com/OGRECave/ogre-next/t ... pts/output

Yes, it should work on macOS as well.
For iOS and Android you probably would need additional work but it is possible.

[dark_sylinc]

How can we get used GPU RAM MB value?

See Samples/2.0/Tutorials/Tutorial_Memory

[Crystal Hammer]

Thanks.
Okay using setDatablockOrMaterialName fixed trails and BillboardSet with flare1 now works.
I also see trails now with

Code: Select all

mSceneMgr->createMovableObject("RibbonTrail", &mSceneMgr->_getEntityMemoryManager(SCENE_DYNAMIC), &params);

but, they are either invisible without

Code: Select all

vertex_colour true

or write in log:

Code: Select all

18:21:04: OGRE EXCEPTION(1:InvalidStateException): Renderable must have at least 2 coordinates in UV set #0. Either change the mesh, or change the UV source settings in HlmsUnlit::calculateHashForPreCreate at ../../Components/Hlms/Unlit/src/OgreHlmsUnlit.cpp (line 364)
18:21:04: OGRE EXCEPTION(1:InvalidStateException): Renderable must have at least 2 coordinates in UV set #0. Either change the mesh, or change the UV source settings in HlmsUnlit::calculateHashForPreCreate at ../../Components/Hlms/Unlit/src/OgreHlmsUnlit.cpp (line 364)
18:21:04: Couldn't apply datablock 'TireTrail' to this renderable. Using default one. Check previous log messages to see if there's more information.

Hmm I can't reproduce that bug with Terra freezing PC on clean Sample_Tutorial_Terrain. I went far away 100km, looked away from terrain a lot, and it works fine.
So it must have been only this issue with my not normalized float terrain, back then too.

But having always normalized heightmap 0..1 seems like a PITA for editor, where max height could change every frame even, if someone is deforming.
So I think I should assume some max height for all tracks? And have it const.
That would be 1300 m today. It recently got this high since a new cool track reached such height range.
But then we're back to similar issues as with 16 bit data (not even mentioning 8 bit) since floats will also loose precision, the higher this scale (max height) will go (while most terrains use low heights). Let's say I'd assume 2048 m, then floats with their 6 digits will be left with roughly just 3, so like 2 mm resolution, am I guessing right? Maybe this is not a problem then, and it'd be much more effort to code Terra it for any range floats right?

So from Tutorial_MemoryGameState.cpp that whole code block computing totalBytesNeeded is what I need for GPU RAM use and I can do it every frame.

I moved with my code to new stuntrally3 repo.

[Crystal Hammer]

Okay so I see some methods in HlmsTerraDatablock *datablock.
But how do I set these properties?

Code: Select all

"detail_weight" :
{
	"texture" : "HeightmapBlendmap.png",
}
"detail0" :
{
	"offset" : [0, 0],
	"scale" : [128, 128],
	"roughness" : 0.5,
	"metalness" : 0.5,
	"diffuse_map" : "grass_ground_d.jpg",
	"normal_map" : "grass_ground_n.jpg",

Code: Select all

datablock->setDetailTextureProperty();

E.g. scale or any texture by name?
Is it maybe possible to just load this whole json from String? I think it'd be easier for me to make that string instead of calling like 10 different confusing methods, which I don't see any example of and can't figure them out from sources.
BTW, is roughness_map and metalness_map always needed for all layers? I'm getting error if I don't have it in json, if so then what do roughness and metalness values do? I'd prefer to use values, since I don't have them as textures, at least for now.

[dark_sylinc]

Well you can either go full C++:

Code: Select all

terraDatablock->setDetailMapOffsetScale( detailMap, offsetScale );
terraDatablock->setMetalness( detailMapIdx, metalness );
terraDatablock->setTexture( Ogre::TERRA_DIFFUSE, diffuseTex ); // or "textureName"
terraDatablock->setRoughness( detailMapIdx, roughness );

Or use JSON:

Code: Select all

hlmsTerra->loadMaterials( "FileName for logging purposes", defaultResourceGroupForLoadingTextures, jsonString, "" );

Where your JSON input is provided through jsonString as a const char*

You can also look at HlmsJsonTerra to see how the JSON maps to C++ calls.

Cheers