Removed

[timl132]

Removed

[xrgo]

there are very good samples in the sample folder, but they all work around a little framwork with some systems and managers that are veeeery useful to start your own engine. there's also an EmptyProject sample that uses that framework to get you started easily.

But if you want something basic... I have this very basic Ogre2.1 project:
https://www.dropbox.com/s/st9ccu2qn5ux6 ... e.zip?dl=0
for QtCreator. You need to replace all the paths with your own (in the .pro and cpp)

hope it helps

Can Ogre3D be used as a bare renderer, so I can manage objects, textures, meshes, lights and such myself?

yes you can, I suggest not doing this at first, once you get more familiar with all the stuffs, replace them with yours

[dark_sylinc]

The more you attempt to do by yourself, the less useful Ogre3D becomes.

It's hard to understand what you're after because it seems you want "a good PBR material system" but at the same time you want to manage everything yourself. These goals are conflicting because PBR means shader code, material info (textures, parameters such as diffuse, roughness, etc), mesh information (how to store and decode normals, deal with skeletal weights and indices for animation, select the right UV, use tangents for normal mapping), and lighting data (type of light, colour, power, direction, position, shadow maps).

Assuming you're knowledge enough to replace these systems on your own (or if you want it as a learning exercise):

• You can avoid Meshes (and hence Items & Entity) by deriving from MovableObject & Renderable and build your own vertex buffers. We show how to do that in the CustomRenderable sample (Samples/2.0/ApiUsage/CustomRenderable/MyCustomRenderable.cpp) and also in the DynamicGeometry sample (Samples/2.0/ApiUsage/DynamicGeometry/DynamicGeometryGameState.cpp)
• You can customize the Hlms implementation or write your own from scratch or using the ones we provide as a base (i.e. your own shaders & materials). The manual has an entire section about Hlms and there are also numerous posts on how to write your own Hlms. Unfortunately, we don't yet provide a tutorial or sample on how to do that.
• Replacing Light would be difficult, as its class is used in CompositorShadowNode for shadow mapping and the Hlms implementations use them as well. Ogre also performs certain culling algorithms assuming the pointer is a Light, and Forward+ works with the Light class as well. It's not impossible, but not trivial and you would have to replace a lot of Ogre code.
• Replacing textures would very hard. Textures aren't just used for sampling, but also for managing RenderTargets and windows, hence tightly integrated into Ogre. You can however, create the textures manually and fill them manually with your data. Use TextureManager::createManual in 2.1, and the flag TextureFlags::ManualTexture in 2.2.

Cheers

[timl132]

Removed

[dark_sylinc]

Thanks, but let me put it a bit different.
What I want to do is provide ogre with UV coordinates, Vertices, Textures, Position, rotation and scale.

Ok, that you can do by either doing what CustomRenderable does, or by manually creating the Mesh (via MeshManager::createManual).

THen i want to be able to do Mesh1.render() or something and have it rendered.
But I want to create a Mesh and Entity myself, put it in my own list, and render it manually.

This may need a very long explanation. I'll try to be brief.

Ogre collects all the "live" objects and culls them against the frustum (to eliminate meshes that are not visible by the camera), then a RenderQueue sorts them out to render efficienctly while the Hlms fills the shader data (like world matrices).
This is called "retained mode".

What you're describing is "immediate mode". Without sorting the list like the RenderQueue does, you may get bad performance (or very wrong results if using transparency).

You can control what objects get rendered in certain ways:

• MovableObject::mRenderable keeps a list of Renderables that can be collected for rendering. For example MyCustomRenderable adds itself to this list: mRenderables.push_back( this ); so it can render. By removing the object from that list, it won't be rendered
• Likewise, the compositor's pass_scene can be set to render a specific range of Render Queues. If you place your MovableObject in a renderqueue ID that is not touched by any pass_scene pass, your object won't be rendered either (or you can call setVisible( false ) instead...)
• You could theoretically write your own Compositor pass (via CompositorPassProvider) and do your own render, by passing almost everything Ogre does, including the RenderQueue. But it wouldn't be a trivial task if you're not familiar with the engine. With this you could do Immediate mode rendering. After all RenderQueue::RenderQueueGroup::mQueuedRenderables is the list of objects we use to render this current frame.

TL;DR it can be done, but you will be constantly fighting the engine, since it's a Retained Mode engine, and you want it to use as an immediate mode. It does make sense for specific passes. For example GUIs can implement their own compositor pass and render in immediate mode style. I am currently writing a (very experimental yet) GUI library that does exactly that. The function Renderable::addCommands handles this immediate mode rendering.

edit:
The thing that kinda bothers me is that I have to setup a things like A GraphicsSystem(Which I can still understand) but I also have to setup an GameState, what is that GameState for, why do I want it, what if i am NOT creating a game?

GraphicsSystem & GameState are part of a framework example on best practices to setup a game (and possibly non-games as well). But you're not forced to follow them at all.

GameState is just a basic FSM (Finite State Machine) implementation. By having multiple states, you can more easily implement main menu as a game state, normal gameplay as another, and a pause menu as another state. Possibly stack them together and have them work at the same time (e.g. gameplay still runs behind the pause menu in a multiplayer game).

Outside a videogame, this FSM may still be useful, as the general concepts often still apply (e.g. "Edit mode" vs "Simulation mode" in a scientific simulation software)

In an application that has only one state, the difference between GameState & GraphicsSystem makes little sense and the two classes could be merged together. However if you need multiple states, this separations allows to more clearly define what tasks performed by your code are specific to the current mode of operations, and what stuff is common to all or most modes/states of operation.

Cheers