Volume Fog important!

[conx]

Sorry if this is not right place for this announcement.
Yes I know that this can be done with shaders. I dug the whole forum and no help in this area.

Volume Fog based on mash is needed!!!
And good example: shader attached to object.


Ogre 2.0 without Volumetric Fog and Volume Light inside is not an Ogre 2.0 but 1.999.

Thank you,
Rafal Lesniewski

[dark_sylinc]

Advanced effects working out of the box like volumetric fog are planned for 2.3 or 2.4+ releases. They're far away for now.

[cord]

The VolumeTex sample is sort of what you're looking for. It's not a complete Volumetric Fog solution, but if you really want to write it yourself, it's a start.

[Xavyiy]

From my point of view Volumetric fog is not something which has to be built-in in Ogre. There are several ways for implementing it, actually it really relies on your pipeline (forward+depth data, deferred, hybrid, ...). A proper sample is the best way to teach people how to create it.

I'm not trying to say that eye-candy content is not needed, in fact I think the lack of good showcasing content is one of the biggest problem that Ogre is facing since some years ago (How many times I've read: "Time to port to Unity3D, graphics in Ogre are crap!" ...), but in form of demos/libraries/components/whatever pluggable, not hardcoding it into the engine!

Xavier

[scrawl]

Not hardcoding that into OgreMain is a no-brainer.

However, I'd also oppose adding too many advanced graphics techniques to the sample browser.
Imo, the purpose of the sample browser should be:
1. From the developer perspective, provide a quick way to test that features are working. The keyword here is low compile time. Therefore avoid cluttering it with samples that aren't for testing a specific feature.
2. From the user perspective, examples how to do SIMPLE things.

It should NOT be an engine showcase for the best graphics you can possibly achieve. This basically comes down to our developer resources. With the huge roadmap for 2.0 (and on top of that, the still large amount of unsolved bugs in JIRA) we need to focus our efforts on the core, or it might be a decade until we get something polished.
Also, consider that even if user XYZ from outside the team implements a cool sample and it gets pulled, it still needs to be maintained by the team. Which typically in the long run takes much more time than actually implementing it.

I'm not saying that we don't need an Ogre showcase. But it's not the Ogre team's job.

[conx]

In my opinion the role of 3D engine is to make things easier.

Imagine that you can create closed mesh and convert it to volumertic fog/smoke, later animate mash by vertexes - this way animate smog/fog, and
all this with 3..10 lined of code. Imagine that you can easly add real shadows, true light reflection, light shafts. Imagine that all objects accepts shadows and create shadows...

For me Orge development stoped. I don't see any nice improvements from last 5 years.
Don't take me wrong I love your work, I love this project. Thats why it is sad form me.

Sentences like "you can use saders" is just bad attitude. Why use Ogre you can use OpenGL or DirectX ...

Sorry,
Thank you for great work.
Rafal

[c6burns]

In my opinion the role of 3D engine is to make things easier.

Then you should do that in your engine, using Ogre as a rendering library.

For me Orge development stoped. I don't see any nice improvements from last 5 years.
Don't take me wrong I love your work, I love this project. Thats why it is sad form me.

Are you confusing Ogre with the SampleBrowser and samples?

Sentences like "you can use saders" is just bad attitude. Why use Ogre you can use OpenGL or DirectX ...

Because in the later versions of DX and OGL ... it's ALLLLL shaders. If you hadn't noticed, the fixed function pipeline is going the way of the dodo. But thankfully Ogre provides RTSS for you as a solution to that issue. Also ... quite obviously ... Ogre abstracts rendering and uses plugins for both systems. Do you want to do that yourself or stand on the shoulders of giants?

[al2950]

@Conx & @C6burns
I can see where Conx is coming from and it does feel like Ogre's development has slowed a bit in terms of exciting features, however that is were Ogre 2.x comes in. Obviously there is quite a lot to a rendering engine than just shading pixels, however I have to admit I also feel like Ogre should do a bit more work in this area instead if saying you can use shaders. Now this is were RTSS comes in, however it turns out its extremely difficult to create a high quality material system which is both flexible and easy to use! The Ogre community is aiming to create a decent material system that does cool things like physically based lighting, screen space reflections, tessellation, etc, but is does require an awful lot of careful planning. If you look to share any opinions/ideas see the following thread;

http://ogre3d.org/forums/viewtopic.php?f=25&t=79006

[c6burns]

Just wanted to add ... I didn't mean to come off super harsh in my tone. Just something about posing the question "Yeah, but what have you done for me *lately*?" to an MIT licensed project (whose value proposition is obvious) seems a bit over the top.

[cfn]

Although I agree that implementing volumetric fog in the ogre core is not the way to go, I think there are some features that might make it easier that could be worth being implemented in the core.

First thing that could be helpful is something like custom screen aligned quads or renderable bounding-boxes or -spheres. The use case I can think of is for "static fog". Say you have in the scene a cube, sphere, you name it with some implicit or explicit density function and want to render that, I would project it into the screen and render a screen aligned quad, or just rasterize the AABB. The actual "volume rendering" would be done in a shader provided by the user. But to get the thing into the rasterizer you have to create a rectangle2d or a manual object and in either case calculate and update the positions your self. This is something that would not only be helpful with volume fog, but also with other "apply fancy shader to this part of the scene"-techniques, especially in the context of deferred shading.

The second thing that could be helpful is a generic point-cloud movable object. Point clouds can be used to render e.g. dynamic smoke or other particles. Using an appropriate shader point clouds can easily be used to create volumetric stuff. Besides being useful for volumetrics, point clouds or rather point based rendering is useful when rendering data obtained by 3d scanners. Again you could do it with stuff we already have, like building manual objects (triangle meshes), setting the rendering method in the material to point or somehow you might be able to hack the billboard system to do what you want.

As stated before, in both cases there are ways to do it with the tools ogre provides. But in both cases it requires hacking existing things to react in the required manner or manually keeping track of scene updates or both. Also both proposed features are general purpose tools and not things tailored to a specific thing as volume fog. These are things that a rendering engine should take care.

[c6burns]

These are things that a rendering engine should take care.

Maybe this is all just an argument over semantics, like people think of "rendering library" meaning something different than "rendering engine" or "renderer". But in my opinion, your renderer should take care of all the things you would normal do directly with the underlying graphics API and that's pretty much it. So managing your scene graph, providing an abstracted interface to deal with multiple underlying graphics APIs, and exposing a plugin interface. And it should do those things extremely efficiently while leaving the rest up to you (or the community/non-core team).

[cfn]

Or maybe this thread is doomed because the first post demanded the implementation of Ogre::performMiracle() Ok, now serious again:

The point rendering abilities of Ogre are extremely limited. Billboards are by default converted to quads. If using native point rendering of the underlying rendering api, most per point attributes are lost and unavailable to the shaders. The behavior I would expect is exposing those parameters to the shaders.
When interfacing with opengl directly, it would be perfectly possible to achieve the same outcome with quad rendering or point rendering (either using a geometry shader to create quads on the gpu, or by calculating the point size in the vertex shader and discarding pixels in the fragment shader). I don't know, and don't want do know how and if this holds for directx, but i strongly assume that it is possible with directx. Therefore it is something that ogre should also be able to do by your argumentation.

The other proposal clearly is something that exceeds the features provided my apis like opengl or directx. So this one is more a "nice to have" and the relevance is more based on opinions.

[c6burns]

Or maybe this thread is doomed because the first post demanded the implementation of Ogre::performMiracle()

Good point

[conx]

In IT/Programming it is only a matter of time.
The question is who will make this first we or them.

Who would imagine in 2005 that this project will get to this point?
I know, truth hurts some times.
Sorry

[AgentC]

Maybe it's just that Ogre's methodology and you aren't compatible.

Ogre aims for flexible, user-definable rendering so it can't dictate a shader/material set on the users. The entire rendering process is based on materials which are not generated by the core library itself. This makes it hard to support certain rendering techniques out of the box, because there's very little assumptions the renderer can make.

Another example: suppose that you wanted soft particles to be a simple boolean setting in Ogre::ParticleSystem. But that requires (in addition to the particle material being compatible with such setting) having a readable scene depth buffer, and an additional depth pass is not something that can happen automatically with Ogre materials. There are ways around that, for example Hydrax library hacks materials during runtime to add a depth pass to them, but that's not foolproof and not something you'd want the core library to be doing.

There certainly would be merit for a rendering library which would say "this is how you must do materials / shaders / rendering" and in turn it would support all the eye candy effects out of the box. It's unlikely that Ogre will become that library. If we're fantasizing about how Ogre could have improved more since 2005 (while keeping its direction/methodology intact), IMO it should have had Ogre 2.0 optimizations a lot earlier

[Gwenn_]

In IT/Programming it is only a matter of time.
The question is who will make this first we or them.

Who would imagine in 2005 that this project will get to this point?
I know, truth hurts some times.
Sorry

The thing is :

• You are right about what would be cool (super-easy API, no complicated stuff, light shaft etc).
  You are wrong about what can be done in Ogre without changing its nature.

Having light shafts (for example) in Ogre would defeat the purpose by forcing a rendering pipeline onto the user, since you can't build something like this in a modular way.

Ogre users have various needs. Some want to use deferred shading, some don't. Some want stencil shadows, others don't. Some want to use a real-time shader system, some don't.
And these are not obvious, general-purpose choices. These define what the user can do or can't. If Ogre was to force some of these choices, a lot of users would lost all interest for it because they wouldn't be able to use it for their purposes.

There is a reason why game engines like Unity or UDK are monolithic. And there is a reason why Ogre is not. I say this as a user of both commercial engines (Source, UDK, UE4 etc) and Ogre.

[AgentC]

Yeah, thinking more of the "year 2005" limit, it's apparent that before the rendering pipeline was, even in AAA games, largely the same everywhere: you'd stuff your opaque objects first, then the transparencies + particle effects, using the fixed function pipeline. Most rendering features would operate on the geometry level, which Ogre supported well: particles, animations, ribbon trails, BSP rendering, terrains etc.

But now you must pick the rendering pipeline based on what you want, and author the shaders to match. Suddenly there can't be an universal setup that produces AAA-comparable quality and pleases everyone, and due to Ogre not providing one, it may unfairly seem that there is no progress.

[c6burns]

Good points above. I think it boils down to the fact that Ogre is not some turnkey CryEngine3 replacement ... thus you can't expect it to hand you everything your project might need. It's all well and good to want someone else to build your eye candy for you (for free) ... but at least let them finish the work they consider more important first (eg. core performance), even if you can't understand their priorities (which you can if you stop and take a few seconds to really consider them).

I never thought I would see someone contend that Ogre is outdated while simultaneously considering the suggestion to use shaders as "bad attitude".

[conx]

c6burns: Learn to read with understanding, stop trolling plz!

Good points above. I think it boils down to the fact that Ogre is not some turnkey CryEngine3 replacement ... thus you can't expect it to hand you everything your project might need. It's all well and good to want someone else to build your eye candy for you (for free)

I dont force anyone to do any thing, I just shared my opinion - thas what forum is fore! Ogre is full of "candy methods" they are helping ppl to work and thats why Orge is popular.

... but at least let them finish the work they consider more important first (eg. core performance), even if you can't understand their priorities (which you can if you stop and take a few seconds to really consider them).

I am waiting from 2008, I can wait few sec more.

I never thought I would see someone contend that Ogre is outdated while simultaneously considering the suggestion to use shaders as "bad attitude".

I didn't say that shaders are outgated! I think the excuse called "shaders" does not explain the lack of progress.

[Gwenn_]

Let's take your "true light reflection" example. How do you suggest Ogre implements it ? In a way that works both with deferred and forward rendering ? That works whatever the user want to do with his pipeline ? It's plainly impossible. Engines that offers that kind of feature out of the box do not offer any choice in the rendering architecture.
Now, of course, one could start a project based on Ogre that offers a higher level interface, with some decisions hardcoded into it. That's basically what game engines do. But it can't be a part of Ogre, for that would weaken it.

The point is : Ogre is not what you need. It's what some people need, and they can't give you "true light reflexions" or "light shafts" without destroying the project for other.

[c6burns]

You need CryEngine3 ... they dictate the entire render pipeline to you and lock you out of the shaders. GREAT! And they give you lots of pretty effects like volumetric fog/light to play with.

[Gwenn_]

Actually game engines don't lock you out of shaders (in commercial versions at least, and in free version for UDK). While this is not the preferred way of dealing with materials, they do offer that possibility. What game engines lock you out of it the rendering architecture. You can't add global illumination to UDK or remove static lightmapping, you are forced to use the (however great) pipeline that was built for you.

[c6burns]

The last time I used CE3 was around Feb of this year. They lock you out of the shaders in that engine, or at least they did at that time. The shaders are packaged in protected archives. It was not clear at that time if access to shaders would be granted with the indie license, since they didn't actually have indie licensing at that time. Perhaps all that has been made clear now.

Anyway my point was more about the contrast between a game engine and a rendering library, and how one can/should dictate many things about how your rendering pipeline works and one can't/shouldn't.