Porting Gorilla

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


N0vember
Gremlin
Posts: 196
Joined: Tue Jan 27, 2009 12:27 am
x 24

Porting Gorilla

Post by N0vember »

Hello,

I am trying to port Gorilla to Ogre 2.0 for my application and I am so far facing two small inconsistencies

1. As far as I understood, Viewports have been "partially ditched" and I just need a RenderTarget now, so I am replacing the Viewports with RenderTarget.
However, Gorilla relies on a FrameListener and determines in the handler whether to render or not depending on if the current viewport being rendered to is the one we want.

Code: Select all

 void Screen::renderQueueEnded(Ogre::uint8 queueGroupId, const Ogre::String& invocation, bool& repeatThisInvocation)
 {
  if (mRenderSystem->_getViewport() != mViewport || queueGroupId != SCREEN_RENDERQUEUE)
   return;
  if (mIsVisible && mLayers.size())
   renderOnce();
 }
Supposing I know have a RenderTarget instead of the viewport, what would be the best way to replicate the old behavior in this handler ?

2. ScreenRenderable objects in gorilla inherit from SimpleRenderable, which now takes two arguments in its constructor, which I have no idea how to fill in a basic way to obtain desired behavior. How can I obtain a TypeId for the Gorilla type ? And how can I setup an ObjectMemoryManager ?

Thanks in advance for any help
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Porting Gorilla

Post by Transporter »

Try this:

1.

Code: Select all

if (queueGroupId == Ogre::RENDER_QUEUE_OVERLAY && Ogre::Root::getSingleton().getRenderSystem()->_getViewport()->getOverlaysEnabled())
2.

Code: Select all

 ScreenRenderable::ScreenRenderable(const Ogre::Vector2& maxSize, TextureAtlas* atlas)
 : LayerContainer(atlas), SimpleRenderable(0, new Ogre::ObjectMemoryManager()), mMaxSize(maxSize)
 {
It would be nice if you could post your changes to create a pull request.
N0vember
Gremlin
Posts: 196
Joined: Tue Jan 27, 2009 12:27 am
x 24

Re: Porting Gorilla

Post by N0vember »

1. I'm afraid it will not work in case Ogre 2.0 really don't use viewports anymore. As far as I understand the concept of viewport is in the Compositor now and has nothing to do with the class Ogre::Viewport, and it is only a set of coordinates for the output quad. In this case the part where you check on the viewport if overlays are enabled would be moot. I'll investigate this.

2. I investigated this one and found the more orthodox way to do it :
TypeId id = Ogre::Id::generateNewId<Ogre::MovableObject>()
ObjectMemoryManager* memoryManager = &sceneMgr->_getEntityMemoryManager(Ogre::SCENE_DYNAMIC)


EDIT : Well it is working ! So I just have to check a few things that it isn't rendering the GUI once per render queue, but at least it's working
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: Porting Gorilla

Post by Transporter »

N0vember wrote:1. I'm afraid it will not work in case Ogre 2.0 really don't use viewports anymore. As far as I understand the concept of viewport is in the Compositor now and has nothing to do with the class Ogre::Viewport, and it is only a set of coordinates for the output quad. In this case the part where you check on the viewport if overlays are enabled would be moot. I'll investigate this.

2. I investigated this one and found the more orthodox way to do it :

Code: Select all

Ogre::TypeId id = Ogre::Id::generateNewId<Ogre::MovableObject>()
ObjectMemoryManager* memoryManager = &sceneMgr->_getEntityMemoryManager(Ogre::SCENE_DYNAMIC)
1. It is working well with libRocket (http://www.ogre3d.org/tikiwiki/tiki-ind ... =libRocket)
2. That's good to know!
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Porting Gorilla

Post by Kojack »

Yep, Viewport isn't used anymore.
(It's still there, but does nothing)

Instead viewports are now done with the mVpLeft, mVpTop, mVpWidth and mVpHeight members of CompositorPassSceneDef.

Here's a little (probably bad, I'm still getting my head around the new system) test I did for Oculus rendering, using some code modified from the samplebrowser.
It creates a render texture and attaches a compositor workspace to it which contains a full size clear pass and two half width scene passes (one for each eye). The passes have the viewport dimensions.

Code: Select all

Ogre::TexturePtr tex = Ogre::TextureManager::getSingleton().createManual("EyeTexture", "General", Ogre::TextureType::TEX_TYPE_2D, 1182*2, 1461, 0, Ogre::PixelFormat::PF_A8R8G8B8, Ogre::TU_RENDERTARGET);

	m_compositorManager = m_root->getCompositorManager2();
	if (!m_compositorManager->hasWorkspaceDefinition("SampleBrowserWorkspace"))
	{
		Ogre::CompositorNodeDef *nodeDef = m_compositorManager->addNodeDefinition("AutoGen " + (Ogre::IdString("SampleBrowserWorkspace") +
			Ogre::IdString("/Node")).getReleaseText());

		//Input texture
		nodeDef->addTextureSourceName("WindowRT", 0, Ogre::TextureDefinitionBase::TEXTURE_INPUT);
		nodeDef->setNumTargetPass(1);
		{
			Ogre::CompositorTargetDef *targetDef = nodeDef->addTargetPass("WindowRT");
			targetDef->setNumPasses(3);
			{
				{
					Ogre::CompositorPassClearDef *passClear = static_cast<Ogre::CompositorPassClearDef*>
					(targetDef->addPass(Ogre::PASS_CLEAR));
					passClear->mColourValue = Ogre::ColourValue(1, 0, 0);
				}
				{
					Ogre::CompositorPassSceneDef *passScene = static_cast<Ogre::CompositorPassSceneDef*>
						(targetDef->addPass(Ogre::PASS_SCENE));
					passScene->mShadowNode = Ogre::IdString();
					passScene->mVpWidth = 0.5;
					passScene->mVpHeight = 0.5;
					passScene->mVpLeft = 0.0f;
					passScene->mCameraName = "LeftCamera";
					}
				{
					Ogre::CompositorPassSceneDef *passScene = static_cast<Ogre::CompositorPassSceneDef*>
						(targetDef->addPass(Ogre::PASS_SCENE));
					passScene->mShadowNode = Ogre::IdString();
					passScene->mVpWidth = 0.5;
					passScene->mVpHeight = 0.5;
					passScene->mVpLeft = 0.5f;
					passScene->mCameraName = "RightCamera";
				}
			}
		}
		
		Ogre::CompositorWorkspaceDef *workDef = m_compositorManager->addWorkspaceDefinition(std::string("SampleBrowserWorkspace"));
		workDef->connectOutput(nodeDef->getName(), 0);
		
	}
	m_compositorManager->addWorkspace(m_sceneManager, tex->getBuffer()->getRenderTarget(), 0, "SampleBrowserWorkspace", true);
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Porting Gorilla

Post by dark_sylinc »

Indeed, viewports still exist but they're for internal use now. The data that was once set directly in the viewport is now in the compositor pass definition.

The most common way to identify a particular pass is by using Compositor passes.

You can set a Workspace listener to listen for passes (passes can have a custom arbitrary identifier, which is an uint32).
Another way is to register a custom pass provider so that a custom pass is executed to draw the Gorilla stuff.
N0vember wrote: 2. I investigated this one and found the more orthodox way to do it :
TypeId id = Ogre::Id::generateNewId<Ogre::MovableObject>()
ObjectMemoryManager* memoryManager = &sceneMgr->_getEntityMemoryManager(Ogre::SCENE_DYNAMIC)
This is the correct way to do it :)
In case you're wondering the rationale behind this (i.e. WHY you have to do that):
1. The ID is supplied externally (rather than asking for an ID in the base class to a static function) in order for future code to be more multithreading friendly. It ought to be possible in the future to have create two MovableObjects from two different threads, each one with independent IDs (i.e. duplicate IDs) as long as the MovableObjects don't end up mixed together (i.e. they're independent, since duplicate IDs aren't valid).
This way multithreaded creation, rendering and maintenance wouldn't have to involve a lock to a single global function (in this case, Id::generateNewId<Ogre::MovableObject>()). Not sure if this idea will work, but the design is there.

2. For now, we have two memory managers (one static, one dynamic). But future, more advanced, scene managers can/will have more memory managers (i.e. one per octant, one per cell grid in a 2D grid, one per portal zone etc). UI stuff ends up probably in a global memory manager, but scene objects may want to end up in a memory manager of the region they belong to (how that is organized will depend on the scene manager implementation)
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: Porting Gorilla

Post by al2950 »

**EDIT** Did not notice dark_sylinc had posted whilst writing this! (there is some overlap)
Ok, well look like you like stating at the deep end!!

I am afraid I dont know Gorilla but I have had a quick look through the source, albeit a very quick view so dont take my help as gospel!

Firstly, you should really get to grips with the compositor system and compositor nodes, it takes a little while to get your head around (partly because its called compositor, even though it is very different from 1.x), but it defines the whole rendering pipeline and is one of the most important parts in Ogre 2.0

Secondly, Gorilla injects rendering commands directly which means you can not use the RenderQueue listener, as Ogre will now ignore empty render queues. So to inject render commands directly you are going to have to use a CUSTOM_PASS compositor node which has only just been added (last week), and so I have not had time to test it. See (http://ogre3d.org/forums/viewtopic.php?f=25&t=81398)

Thirdly the "ScreenRenderable" which inherits from SimpleRenderable and therefore MovableObject never really uses the MovableObject as it was supposed to use it. What I mean is that it creates a SimpleRenderable but never actually adds it to Ogre, it just uses some of its functions and other useful attributes as far as I can tell, so ogre does not know about it and so you dont really need to worry about the TypeId stuff, although its a bit hacky!

Hope this helps!
N0vember
Gremlin
Posts: 196
Joined: Tue Jan 27, 2009 12:27 am
x 24

Re: Porting Gorilla

Post by N0vember »

Well, for the 2D screens :
- Setting a default workspace definition provided by Ogre
- and replacing Viewport* with RenderTarget* in Gorilla code
The result is Gorilla manages to draw itself just fine directly on the RenderTarget.

Note that I'm just using 2D Screen and not 3D ScreenRenderable so I didn't test that.
So it seems gorilla way of using RenderOp manually to draw itself flat still works fine without needing a custom pass.
Any idea why would that be, and a good rationale for actually migrating the code so that it would use a custom pass ? Is the manual RenderOp gonna be deprecated one day. Or is it slower ?

My guess is that the method of using a custom pass is needed for the 3D ScreenRenderable which I don't use for now in my application, so I guess I'm not the one who's gonna adapt that part.
dark_sylinc wrote: 2. For now, we have two memory managers (one static, one dynamic). But future, more advanced, scene managers can/will have more memory managers (i.e. one per octant, one per cell grid in a 2D grid, one per portal zone etc). UI stuff ends up probably in a global memory manager, but scene objects may want to end up in a memory manager of the region they belong to (how that is organized will depend on the scene manager implementation)
Yeah I agree that UI objects are gonna be in a global manager. I actually already modified Gorilla to have multiple viewports, so it goes together with the idea of an overarching UI and multiple viewports / scenemanager with their own memory manager. The way I do is I have one empty SceneManager just for the interface, since it was the way Gorilla and Ogre are already "setup". You can't really draw anything without a SceneManager anyway.
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: Porting Gorilla

Post by al2950 »

N0vember wrote: So it seems gorilla way of using RenderOp manually to draw itself flat still works fine without needing a custom pass.
I think it is because of these lines in the scene manager;

Code: Select all

void SceneManager::initRenderQueue(void)
{
    mRenderQueue = OGRE_NEW RenderQueue();
    mRenderQueue->getQueueGroup(RENDER_QUEUE_OVERLAY); //TODO: This feels hacky to get Overlays working
}
Basically it generates a render queue for RENDER_QUEUE_OVERLAY so it will be included in the render if you ask to render it, and it is that render queue Gorilla is looking at. That hack might be fixed at some point!

There is an "overlays" part to a compositor node, which sets the viewports setOverlaysEnabled, which in turn is passed to SceneManager::_renderPhase02, but it does not do anything yet.

@dark_sylinc - Is there a plan for the includeOverlays variable in _renderPhase02
N0vember
Gremlin
Posts: 196
Joined: Tue Jan 27, 2009 12:27 am
x 24

Re: Porting Gorilla

Post by N0vember »

Okay so it seems having an empty RenderQueue is the way to go for now. Anyway by design I need an empty SceneManager too so why not an empty RenderQueue ? I don't really see any negatives here. The possibility to add this render queue manually will still exist, or will it not ?

I have another question :
I have created in total, a hidden RenderWindow (1. the main one), a visible RenderWindow (2. the actual one I draw gorilla to), and a RenderTexture (3. where I draw my "viewport" under the interface overlays)
These are the only RenderTargets I created.
I have created added one workspace for the RenderWindow (2.) and one workspace for the RenderTexture(3.)
Now in the framelistener, I thought well if there should be only one viewport on the rendertarget, I could as well check that the Viewport being drawn to in that frame event is the Viewport at index 0 of my RenderTarget, and if it is then draw the GUI.

Code: Select all

void Screen::renderQueueEnded(Ogre::uint8 queueGroupId, const Ogre::String& invocation, bool& repeatThisInvocation)
{
    if(mRenderSystem->_getViewport() == mViewport->getViewport(0))
    [...]
}
Except that didn't work out of the box because I discovered there are actually already two Viewports on this RenderTarget and the correct one is the second (so at index 1). Which is strange because I surely didn't create the first one, at least not explicitly. And if the Workspace would create one, then there should be one right.
So, why would there be 2 Viewports on that RenderWindow already ?
Is that a feature or a bug ? :p
Could we have a bit of information on when exactly are Viewports added to the RenderTarget by Ogre ? I know it's supposed to be internal, but it's still exposed in the interface soo....

Also, I understood that the better way to do it would be through a Workspace listener, to listen for passes, but since I'm lazy and the current approach works I'm not gonna clean it for now because I'm spending my time on something else, hehe
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Porting Gorilla

Post by dark_sylinc »

al2950 wrote:@dark_sylinc - Is there a plan for the includeOverlays variable in _renderPhase02
Well... the plan actually is to eventually get rid of the "includeOverlays" variable.
The plan is to refactor the RenderQueue so that IDs start at 0 until an arbitrary number (max limit is 255 though). Their meaning is set by the user. Pretty much like in Unity. But the CTP version didn't refactor the RQ; so we still have those crazy "10", "50", "96" magic numbers in the render queue.

Ideally, the user will tell the GUI plugin on which RenderQueue ID it wants the plugin to render to (which the plugin should honour) and the user prepares the compositor with the right RQ ID (another way is the plugin accepting a workspace definition and adding the passes itself).

This is very flexible because the user can control when the UI gets rendered: At the beginning, in the middle, or after other passes (from regular scene passes to compositor effects).

The reason "includeOverlays" exists is simply because it was the fastest way to get Overlays working again without breaking too many things, and the RQ refactor didn't happen yet.
N0vember wrote:Except that didn't work out of the box because I discovered there are actually already two Viewports on this RenderTarget and the correct one is the second (so at index 1). Which is strange because I surely didn't create the first one, at least not explicitly. And if the Workspace would create one, then there should be one right.
So, why would there be 2 Viewports on that RenderWindow already ?
Is that a feature or a bug ? :p
The compositor added the first Viewport. It may even add more than one.
For example in split-screen multiplayer (2 players), one pass would draw to the top half (1st player), the second pass would draw to the bottom half (2nd player). The workspace's node would have two nodes, and the compositor system will create one viewport, one for each half.
The compositor will share/reuse viewports when it can.
N0vember wrote:Could we have a bit of information on when exactly are Viewports added to the RenderTarget by Ogre ? I know it's supposed to be internal, but it's still exposed in the interface soo....
It may be worth remembering that public functions starting with _underscore mean they're for internal usage. They may be exposed either for advanced users or because of interface design limitations. That doesn't mean you shouldn't use it.
But like I said, the best method to identify passes is using compositor pass identifiers.

As for the question (when do viewports get created), inside CompositorPass::CompositorPass, the code checks whether an existing Viewport can be used by that pass, otherwise creates a new one that can.
N0vember
Gremlin
Posts: 196
Joined: Tue Jan 27, 2009 12:27 am
x 24

Re: Porting Gorilla

Post by N0vember »

dark_sylinc wrote:
al2950 wrote:@dark_sylinc - Is there a plan for the includeOverlays variable in _renderPhase02
Ideally, the user will tell the GUI plugin on which RenderQueue ID it wants the plugin to render to (which the plugin should honour) and the user prepares the compositor with the right RQ ID (another way is the plugin accepting a workspace definition and adding the passes itself).
This makes much more sense to me also. Doesn't sound more complicated than the current way of rendering GUI anyway, but with more flexibility and control.
dark_sylinc wrote: It may be worth remembering that public functions starting with _underscore mean they're for internal usage. They may be exposed either for advanced users or because of interface design limitations. That doesn't mean you shouldn't use it.
I was just curious why there are already two viewports on my RenderTarget, each taking the full screen surface, where I only setup one Workspace per RenderTarget, and didn't create a Viewport manually. It may be related to how the default workspace handle things, but it looks too me like something wrong either in Ogre code or in my code if there are already two superposed viewports. (and might cause confusion to someone some day, whether this person is dealing with Ogre internals or just using its external)

Also I'm not trying to split hairs here, but getViewport on RenderTarget is still public interface (doesn't have underscore), even though I got it that Viewports in general are not supposed to be :)

EDIT: Okay, finally I investigated this and found out that the default Workspace definition creates one node with two passes, PASS_CLEAR and PASS_SCENE.
PASS_CLEAR is setup from a definition without overlays, whereas PASS_SCENE wants them.
So they end up both creating a viewport. The first one (index 0) for the PASS_CLEAR and the second one (index 1) for the PASS_SCENE.
It doesn't really makes a lot of sense to me that these two passes would operate on different viewport, but I guess it's because I have a different idea of a Viewport than what it now actually is as of Ogre 2.0. I suppose it is that Viewport is actually a completely abstract concept containing information and since they have the same dimensions both passes end up operating on the same actual "viewport" (which would be just a part of the RenderTarget). Could you shed some light ? It will at least make me savier about the new compositor system and its passes :)
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: Porting Gorilla

Post by Thyrion »

someone got gorilla working, with the current 2.0 source and directx 11? =)

seems like it needs shaders?
"Attempted to render to a D3D11 device without both vertex and fragment shaders there is no fixed pipeline in d3d11 - use the RTSS or write custom shaders.",
"D3D11RenderSystem::_render"

will be the RTSS system replaced with HLMS ?
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: Porting Gorilla

Post by al2950 »

Thyrion wrote: seems like it needs shaders?
Yes with Dx11, although keep in mind the Dx11 in the Ogre 2.0 branch has not been merged with all the recent Dx11 work so I would not advise spending too much time with Ogre 2.0 and Dx11 in its current state.
Thyrion wrote: will be the RTSS system replaced with HLMS ?
Yes
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: Porting Gorilla

Post by Thyrion »

:(
N0vember
Gremlin
Posts: 196
Joined: Tue Jan 27, 2009 12:27 am
x 24

Re: Porting Gorilla

Post by N0vember »

Hey thyrion, sorry I didn't respond to your PM earlier.
Here is my personal copy of Gorilla, modified to work with Ogre 2.0. However, I tested it only with OpenGL. I don't know anything about DX11.

There is two includes you should remove for it to work, probably (actually they were added when I was trying to make DX11 work).
Just remove these three lines at the top and it should compile just fine :

Code: Select all

// @MONK
#include <Front/MONKFrontConfig.h>
#include <Front/Ogre/MONKOgreRTShaderFix.h>
Also, keep in mind I modified it a bit for my personal uses : I added a Viewport class and a addViewport function to Silverback because I needed multiple viewport support inside of the UI.
So the Viewport class manually renders a quad to the UI for each viewport before anything else is drawn, with a given material which should contain the RTT.
But you don't need it so it should work as expected in the usual way, I just didn't test it.
Gorilla.h
(75.9 KiB) Downloaded 407 times
Gorilla.cpp
(74.51 KiB) Downloaded 399 times
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: Porting Gorilla

Post by Thyrion »

thx November for your feedback! :)
  • with directx9 it renders without problems.
  • But with directx11 it wants shaders.
  • The RTSS will be replaced and the HLMS isnt available.
  • Directx9 will be removed from 2.0.
  • I need directx for wpf D3dImage
  • already made the switch to 2.0 (already over a year promised :P)
Conclusion: find out how to write a shader for it (or maybe i just made something wrong), or run away! :)
frostbyte
Orc Shaman
Posts: 737
Joined: Fri May 31, 2013 2:28 am
x 65

Re: Porting Gorilla

Post by frostbyte »

I need directx for wpf D3dImage
imho you should find a work-around( e.g http://spout.zeal.co/ )
or just dump the wpf - i know its a tough decision- but might save you future pain...and i feel that wpf dont make you happy anymore :(
i guess qt is ok for a framework but iv'e come to conclusion that the best way is to use only ogre and mygui...
mygui is quite cool( there is even a node editor animation blending example...) and i guess that anyhow youl'e need a gui frame-work integrated to your engine ,also if you go this way then your'e editor can work on all of ogre supported platforms( which support c# )... 8)

the big problem i see with "only dx" engine editor( beside the fact it only works on windows ) is that youl'e have to jump some hoops if you ever want to use the output( game ) in a non windows platform...
the woods are lovely dark and deep
but i have promises to keep
and miles to code before i sleep
and miles to code before i sleep..

coolest videos link( two minutes paper )...
https://www.youtube.com/user/keeroyz/videos
N0vember
Gremlin
Posts: 196
Joined: Tue Jan 27, 2009 12:27 am
x 24

Re: Porting Gorilla

Post by N0vember »

Yes I hate Qt personally. Most cumbersome way to integrate Ogre in an application...
Not to mention you will soon be able to use my own Ui solution :)
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: Porting Gorilla

Post by Thyrion »

ok a bit offtopic -_-
frostbyte wrote:
I need directx for wpf D3dImage
imho you should find a work-around( e.g http://spout.zeal.co/ )
or just dump the wpf - i know its a tough decision- but might save you future pain...and i feel that wpf dont make you happy anymore :(
i guess qt is ok for a framework but iv'e come to conclusion that the best way is to use only ogre and mygui...
mygui is quite cool( there is even a node editor animation blending example...) and i guess that anyhow youl'e need a gui frame-work integrated to your engine ,also if you go this way then your'e editor can work on all of ogre supported platforms( which support c# )... 8)

the big problem i see with "only dx" engine editor( beside the fact it only works on windows ) is that youl'e have to jump some hoops if you ever want to use the output( game ) in a non windows platform...
  • http://spout.zeal.co looks interesting, but how could it be a workaround?
  • wpf and c# in general makes me super happy for app development :)
  • i don't get your last point. what hoops do you mean? the game itself is c++ only and independent from C# or wpf
just some c# game editors examples that are only working in windows:
  • havok editor(PA)
  • Neoaxis
  • sony
c# makes your life much, much easier, compared to c++. That's a reason i don't like the UE4 Editor. How bigger a project grows in C++ , the difficulty to debug/extend grows with it (in my experience).
c# wasn't invented or got that popular without a reason.
Yes I hate Qt personally. Most cumbersome way to integrate Ogre in an application...
Not to mention you will soon be able to use my own Ui solution :)
eagerly waiting for it :)

back to topic:
luckily betajaen already added shader based materials https://github.com/betajaen/gorilla. But i'm still having problems with the shader generation :)
frostbyte
Orc Shaman
Posts: 737
Joined: Fri May 31, 2013 2:28 am
x 65

Re: Porting Gorilla

Post by frostbyte »

http://spout.zeal.co looks interesting, but how could it be a workaround?
oh, didn't realize they are now focused on video transport solution...any way digging a bit deeper into this app...https://github.com/leadedge/Spout2
it basically gives painless transport between gl<-->dx texture, and if hardware allows it without any performance lose( nv_interop extension )
you can use rtt in your editor but translate it into ogreWindow in the executable( game )...
on some hardware which don't support nv_interop there might be some fps drops...http://spout.zeal.co/faq/ ( but it will only be in editor anyway... )
while not a perfect solution it will allow you to use the opengl backend inside your editor...
as a side effect you also get the ability to interact with external application ( e.g a free "record/stream my game video" plugin 8) )

iv'e googled for wpf opengl interop solution but i'm sure you've already dig in the subject...( i was suprised to see so many results, did none of them work? )
what hoops do you mean?
mainly referring the fact that you can't edit/debug opengl shaders/materials in your editor...guess with hlms it will become less important :)
c# wasn't invented or got that popular without a reason.
i've got nothing bad to say about c#....nor against wpf...since i use neither of them...
i just prefer gui to be cross platform and play nicely with dx/gl/input apis...i also like having power over the gui lib...
mygui while lacking some functionality is a perfect fit( again... imho )
iv'e only dealt with mygui but i guess any lightweight gui lib which is not cegui( maybe it's ok if you manage to build it :lol: ) can do the job...

That's a reason i don't like the UE4 Editor. How bigger a project grows in C++ , the difficulty to debug/extend grows with it (in my experience).
while this is generally true, a good modular design is the base for any complex software - without this c# won't help much....
but yeah... developing/compiling with c++ can be a bit depressing...( i guess that is why ogitor don't get much love... :( )
Yes I hate Qt personally. Most cumbersome way to integrate Ogre in an application...
small nail big hammer....

ok... i'll stop now with thread hijacking( one of my specialties :wink: ) ...have fun....
the woods are lovely dark and deep
but i have promises to keep
and miles to code before i sleep
and miles to code before i sleep..

coolest videos link( two minutes paper )...
https://www.youtube.com/user/keeroyz/videos
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: Porting Gorilla

Post by Thyrion »

is there a replacement for sampler2D?
It looks like updating the gorilla shader to dx11, it needs a SamplerComparisonState:http://msdn.microsoft.com/en-us/library ... 85%29.aspx
this shader throws: Error: X3013: 'Sample': intrinsic method does not take 2 parameters

Code: Select all

Texture2D <float4>   myTex;

float4 main_fp(float2 texCoord : TEXCOORD0,
	float4 color : TEXCOORD1,
	sampler2D atlas : register(s0)) : SV_TARGET
{

	return myTex.Sample(atlas, texCoord) * color;
}
didn't find something related in the source/doc for SamplerComparisonState.

original shader:

Code: Select all

float4 main_fp(float2 texCoord : TEXCOORD0,
			   float4 color : TEXCOORD1,
			   sampler2D atlas : register(s0)) : COLOR
{
	return tex2D(atlas, texCoord) * color;	
}
Last edited by Thyrion on Wed Jan 14, 2015 9:40 pm, edited 1 time in total.
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: Porting Gorilla

Post by Thyrion »

Code: Select all

void main_vp(in float4   position  : SV_Position,
	in float2   uv : TEXCOORD0,
	in float4   color : COLOR0,

	out float4 oPosition : SV_Position,
	out float2 oUv : TEXCOORD0,
	out float4 oColor : TEXCOORD1)
{
	oPosition = position;
	oUv = uv;
	oColor = color;
}

Texture2D <float4>  myTex;

float4 main_fp(float4 position : SV_Position,
	float2 uv : TEXCOORD0,
	float4 color : TEXCOORD1,
	SamplerState  atlas : register(s0)): SV_TARGET
{
	return myTex.Sample(atlas, uv) * color;
}
ok, seems to work.
Last edited by Thyrion on Wed Jan 14, 2015 9:39 pm, edited 1 time in total.
User avatar
Thyrion
Goblin
Posts: 224
Joined: Wed Jul 31, 2013 1:58 pm
Location: germany
x 8

Re: Porting Gorilla

Post by Thyrion »

dark_sylinc wrote:Another way is to register a custom pass provider so that a custom pass is executed to draw the Gorilla stuff.
do u have an example? sounds like a clean solution.
xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 168

Re: Porting Gorilla

Post by xrgo »

Hello!!
I am having trouble with gorilla on ogre 2.0,
I downloaded N0vember's version (Thank you!!) but I cant see anything. can someone give me an example on how to show some simple text?
I am doing this:

Code: Select all

    Gorilla::Screen* gorillaScreen;
    Gorilla::Layer* gorillaLayer;
    Gorilla::Caption* gorillaCaption;

    Gorilla::Silverback* silverBack = new Gorilla::Silverback();
    silverBack->loadAtlas( "myFont" );
    gorillaScreen = silverBack->createScreen(sceneManager,renderWindow->getViewport(0)->getTarget(), "myFont");
    gorillaLayer = gorillaScreen->createLayer();
    int fontSize = 40;
    gorillaCaption = gorillaLayer->createCaption(fontSize, 0, 0, "HELLO WORLD");
    gorillaCaption->width(1280);
    gorillaCaption->height(720);
    gorillaCaption->align(Gorilla::TextAlign_Left);
    gorillaCaption->vertical_align(Gorilla::VerticalAlign_Top);
    gorillaCaption->colour(Ogre::ColourValue(1,1,1,1));
I dont get any error, but I think the problem is here:

Code: Select all

silverBack->createScreen(sceneManager,renderWindow->getViewport(0)->getTarget(), "myFont");
because as I understand you cant use the texture from the renderWindow (?) from the porting manual:
By default you cannot use the main RenderTarget as a texture (because it's usually the RenderWindow and D3D and OpenGL don't allow it), and doing it may result in a crash.
I don't get a crash..

so I am guessing Iam just using it wrong

Thank you very much in advance!
Post Reply