by Matias Goldberg | Aug 4, 2019 | News
We’ve often been told building Ogre from source is hard.
And they’re right!
Which is why we tried our best and prepared quick start scripts that will clone all necessary dependencies, configure CMake and build for you!
Grab the download scripts:
Unzip them and run the script that matches your platform and OS!
For example if you’re on Windows and have Visual Studio, run either:
- build_ogre_Visual_Studio_15_2017_Win32.bat
- build_ogre_Visual_Studio_15_2017_x64.bat
depending on the architecture you want to build for (e.g. 32-bit vs 64-bit)
The scripts will automatically start building, but you will also find the Visual Studio solution files under Ogre/build/OGRE.sln
If you’re on Linux, run either:
- ./build_ogre_linux_c++98.sh
- ./build_ogre_linux_c++11.sh
- ./build_ogre_linux_c++latest.sh
Which one you need depends on the C++ version you’re targetting. C++98 compiles much faster than the rest, but may have incompatibilities (particularly with std::string) if mixed in a project build for C++11 or newer
There are currently no build scripts for Apple ecosystem. For building for iOS, refer to the Setting up Guide. The instructions for Linux should work for building for macOS, but may require additional manual intervention.
We hope this makes your life easier! And let us know if you encounter problems with these scripts! The goal is that building Ogre from scratch becomes as simple as tapping a few clicks.
Further discussion on forum post.
by Matias Goldberg | Aug 4, 2019 | News
Hoo boy! This report was scheduled for January but couldn’t be released on time for various reasons.
We have another report coming as this is old news already! We have another report coming mostly talking about VTC (Voxel Cone Tracing) which is a very interesting feature that has been in development during this year.
But until then, let’s talk about all the other features that have been implemented so far!
(more…)
by Matias Goldberg | Jul 8, 2019 | News
If you’re tracking our repo you may have observed we renamed the v2-2-WIP branch into v2-2
What does this mean?
It means the branch is stabilizing. Back when it was v2-2-WIP, it was very unstable. Checking out that branch meant you could find crashes, memory leaks, missing or broken features; and the API interface was changing very quickly, thus updating the repository could mean your code would no longer compile and required adapting.
Over the last couple months, the API interfaces on 2.2 had begun to settle down, bugs were fixed and there were no apparent leaks. In fact some teams started already using it.
Now that it is no longer WIP, while there could still be API breakage on the 2.2 branch or accidental crashes/regressions, it shouldn’t be anything serious or that requires intensive porting.
We still have a few missing features (such as saving textures as DDS) but they’re not used frequently.
Coming up next
We still owe you a Progress Report of what’s been going on in 2.1 and 2.2 in the past year and a half; we have that written down but still needs a few reviews.
Coming up next is:
- More real time GI improvements
- VR performance optimizations
- We are planning on a Vulkan/D3D12 backend
Additionally we have a community member working on GPU-driven rendering and GPU particle FXs; while another community member just contributed Morph animations to 2.1
Yes, Morph animations are finally HW accelerated again! We are evaluating on porting this contribution to 2.2; it shouldn’t take long but we’re evaluating if it can be improved with the use of Compute Shaders
What about Ogre 2.1?
If someone wants to teach Matias aka dark_sylinc a quick automated way to create installer SDKs, that is welcomed! (he never liked handling that!!!)
Ogre 2.1 has been very stable. Eugene ported several improvements from the 1.x branch; and we currently are dealing with a regression that caused due to how PF_BYTE_LA / PF_L8 format is treated in D3D11, but other than that 2.1 is ready for release.
The morph animation contribution is brand new so that may need a bit more testing.
If you don’t see an SDK that is mostly due to time and knowledge to package an SDK.
If someone else wants to step in and maintain packaging, that is welcomed!
Further discussion in the Forum Post
by Matias Goldberg | Jan 1, 2018 | News
Wow! It’s been a long time since the last report.
A lot has happened since last time, so I thought and was pressed to inform of what’s new. I (dark_sylinc) have been bugged by two people on Twitter to write this update, so you can thank them for this report!
But first of all, Merry Christmass and Happy New Year!!!
If you don’t celebrate any or all of the two, then have a great day anyway!
(more…)
by Matias Goldberg | Dec 23, 2016 | News
Merry XMas! if you don’t celebrate it, good wishes anyway!
It’s been 9 months since our last progress report. We think it’s time for a new one! Oh boy. So much has been done and still in the works.
Metal Support
In case you didn’t notice: Ogre 2.1 now runs on Apple’s API Metal. And it’s stable! It only works on iOS for the moment, since a few tweaks are required to make it work on macOS as well.
You’ll need to use the 2.1-pso branch in order to use Metal. The 2.1-pso branch is scheduled to be merged with 2.1, once testing of the branch 2-1-pso-cache-legacy finishes (which implements a PSO cache utility meant to help users port their immediate style rendering code such as GUIs to support PSOs without major/significant changes).
MSAA resolving for D3D11
MSAA for Render Textures has been broken on D3D11 since like…forever. Not anymore. D3D11 MSAA targets will now be resolved appropriately, according to our implicit resolve rules (explicit resolve support still pending, but in that regard OpenGL is in the same state).
Parallax Corrected Cubemaps
PCC for short, aka Local Cubemaps, Local reflections, Cube projection.
PCC reflections are very important to achieve accurate local reflections.
View post on imgur.com
Our PCC implementation has two modes of operations: Automatic & Manual. Both have their strength and weaknesses.
Automatic “just works”. Probes get automatically blended together (based on camera position) and applied. However automatic may have trouble showing reflections from distant probes, and in some cases the blending may be too evident.
Manual solves the problem of distant reflections not showing up and the blending issue, but it requires you to explicitly set the probe to the material. Also if you don’t perfectly subdivide the geometry to fit the probe’s bounds, you may see gaps (since there is no blending happening at all).
You can actually mix automatic and manual behaviors.
Once the texture refactor is ready (keep reading) we may provide more powerful and superior automatic methods (by using Clustered Forward to select which probe to use and cube arrays to do the actual selection, which are only supported on DX11 class hardware or better).
For more information and experimentation you can look at our two samples LocalCubemaps and LocalCubemapsManualProbe.
Important note: The samples don’t make it yet too obvious that the PCC system reserves one visibility mask + Render Queue for their internal computations (i.e. it stores its Items into a RenderQueue of your choosing, set with a visibility bit also of your choosing). If you accidentally try to render those items, it will look funny. Keep in mind they may affect other things too, such as ray picking and Instant Radiosity generation (remember to filter those objects out).
Created Ogre 2.1 FAQ in the Wiki
We’ve addressed it in a news post already. We’ve written a wiki resource to address frequently asked questions regarding Ogre 2.1.
Texture Matrix Animation in Unlit
This has been requested a lot. Now you got it!
While we don’t yet provide easy ways to animate textures using material commands like old 1.x materials did, at least it’s now possible to animate them by hand if you need to.
Global Illumination
We’re working on a technique called Instant Radiosity. The idea is very simple:
- Trace a lot of rays from the light.
- Generate a point light where the ray hits the surface. We’ll call this point light a VPL (Virtual Point Light)
- Cluster very close VPLs into one by summing their light contribution and averaging their locations.
- Use Forward3D or ForwardClustered (or Deferred Rendering) to use all these VPLs in scene.
The technique is an approximation but the results are very convincing, and lots of knobs to adjust for tweaking the results efficiently.
Instant Radiosity is not a very slow technique but neither a real time technique. When it comes to generating the VPLs, we still need to raytrace. Even if the raytrace takes e.g. 500 ms, it’s not suitable for real time. It was chosen because it was easy to implement and offers a lot of flexibility when compared to other techniques (such as Light Propagation Volumes) due to all the settings that can be adjusted, while also illuminating dynamic objects. In other words, the cost benefit ratio was really good.
This image is only lit by a spotlight + Global Illumination:
View post on imgur.com
And now same scene with VPL debug markers turned on:
View post on imgur.com
Another angle with parameters exaggerated:
View post on imgur.com
Clustered Forward
Instant Radiosity made it obvious that Forward3D was under-performing. While it was original research done by me (dark_sylinc), it was clear it wasn’t as well as I had estimated and hoped.
So I just went ahead and implemented Clustered Forward. It’s both threaded (slices are assigned to different threads) and SIMD optimized. Also the Frustum vs. Spotlight and Frustum vs. Pointlight intersection tests are much (!) tighter than the ones we use for Forward3D.
In debug builds, having many slices may take a noticeable hit on CPU when compared to debug Forward3D. Though you could just use less slices during debug, or switch to Forward3D.
Clustered Forward allows controlling many slices, which improves GPU speed and the tight frustum tests mean shaders don’t waste precious cycles trying to shade with lights that aren’t actually visible. This leads to an average performance improvement of 33%, though your mileage may vary (it can be 2x faster or 0x if your lights had gigantic ranges).
Compositor improvements
- Scene passes now have “enable_forwardplus” to explicitly turn of Forward3D and ForwardClustered in passes you don’t need them. This will improve CPU consumption by avoiding wasting cycles in building the light lists on something you won’t be using.
- Compositor workspaces now support more than one input (i.e. not just the “final target”, which was usually but not always the RenderWindow). “connect_output” still exists, but it just does the same as “connect_external 0”. Useful when you want a workspace to produce a lot of results for you, not just one.
- 2D Array textures, cubemaps in compositors: They can now be created via compositor scripts. See the manual for more information.
- UAV Buffers: Instead of creating UAV textures, you can also create buffers. We allow creating buffers of fixed byte sizes, and width x height sizes. You can also create them from C++ and treat them as external buffers for the workspace (they work just like external textures). Useful mostly for compute and some advanced rendering algorithms. See the manual for more information.
- Double-sided stencil: Some parameters have been moved to the “both” block. See Sample_StencilTest and the manual for more information.
Quadratic behavior when loading meshes
User 0xC0DEFACE noticed loading 60.000 meshes was taking more than 15 minutes due to O(N^2) behavior in our code. He fixed it with a very trivial change and brought it down to 4 seconds. Kudos!
Merged PSO branch
PSO had been very stable for a long while now. Plus there had been a bunch of very important bugfixes (like stencil support, some edge case viewport glitches) that were only in PSO branch.
Furthermore I found myself very often merging and cherry-picking between the different 2.1 branches, which is a sign that they needed to be merged. So I did.
The last non-pso commit was 06631aef218d73fdc2ca323da626a53650d941be
GLES3 Progress
New user Hotshot5000 has stepped up to port the GLES3 RenderSystem to Ogre 2.1.
He’s claiming he is starting to see the light. We wish him good luck as we wait impatiently for more updates from him!
In Design: Texture Refactor
The texture refactor was announced. No coding work has been done yet, but we’re solidifying the foundations how texture loading will work in the future.
