[submitted] Scene manager

Threads related to Google Summer of Code
Post Reply
User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Sat Aug 26, 2006 10:18 pm

Lee, I think you're missing how the whole things works, on a grand scale. Open up your mind for a second.

If I understand correctly, the occlusion mesh doesn't even need to be rendered into the scene. It's used for portal/cell visibility - it's low res, and doesn't represent your level geometry. Your true level geometry is going to be a high resolution mesh with fancy materials applied. It's up to the lower level scene managers, not the master scene manager, to know how to deal with these meshes and the material problems you've mentioned.

If occlusion culling can be done by a scene manager then I couldn't care less about your "plugin" to Ogre or the fact that you don't think it should be done by a scene manager (if I'm understanding you correctly). A scene manager's job is in fact to do exactly that - manage the scene - including what should be visible.
0 x

Lioric
Google Summer of Code Mentor
Google Summer of Code Mentor
Posts: 295
Joined: Fri Aug 06, 2004 10:25 pm

Post by Lioric » Sat Aug 26, 2006 10:27 pm

It's time you don't have the time so you cutt corners.
But please tell people what it dosn't do. Or they belive otherwise.

Feeling and look has with performance to do in the end if you saturate the system.

Well if you just have one pass one material and two objects on the screen you won't have any problem. Look and feel is OK.

But if you want to use DX9 Sm3.0 features and do some heavy scenes you need to save your computers energy and put it where it counts.

.....
I dont understand a word of your post (no offense) ;)
If Ogre had a general robust hw occlusion query support we wouldn't see this half solutions.
What more general than submit the query to the engine and then get the result when you want/need, this is currently in ogre, what specialization you do in your application (client applications) is your issue
I also mean that any solutions that only use bb has tio high fill rate cost.
For BB's with the simplest material and the simplest settings? have you ever done any performance bechmark?
Using boxes... well that’s fine to start learning hardware occlusion or doing a little specialist thing. It's not what the manual suggests.
What manual? we are here to innovate, not to do what the "manual" dictates, if any "not by the book" approach serves better for your specific needs, then its ok

All in game dev is a "hack", starting by using vertices rasterized over a 2d space to represent volumetric geometry/shapes, there is no a "correct" method for a single thing, that is what programming and evolution is, different solutions for similar problems
There might be applications out they’re stopping and waiting for a query to be ready. Next you will claim that’s OK too? Having the CPU sitting idle doing nothing is one of the seven sins.
If, for their specific needs, this serves them, then why it will be wrong?
I didnt claim that any particular implementation is Ok or not OK, i posted that there are "usable" and "non usable" implementations and that depends on the specific target/needs, that is where we disagree

Without prior tersting of fakaron's implementation, we cant assert if its ok or not ok for "that" specific need, we should first review it and then propose modifications, 2nd level optimizations, or even algo rewriting, or if after testing this is "OK" keep the development iterations
Last edited by Lioric on Sun Aug 27, 2006 2:54 am, edited 2 times in total.
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Sat Aug 26, 2006 10:39 pm

look at the wiki Lee04 -> "more debugging and testing needed". For materials, u don't need them for the occluders nor for the portal, they are not going to be in the final rendered scene!!! why the hell u want to put material on occluders and portal when they are not going to be rendered to the final scene? I m not using Hierarchical occlusion methods nor using techniques used in GPU Gems I & II. occlusion queries are used for portals! the concept is simple.

@Falgard: u understood the concept right :)
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Sat Aug 26, 2006 11:02 pm

If I understand correctly, the occlusion mesh doesn't even need to be rendered into the scene. It's used for portal/cell visibility - it's low res, and doesn't represent your level geometry. Your true level geometry is going to be a high resolution mesh with fancy materials applied.

So the walls are not the walls? That explain things then you can use the same material on the walls and all occluders even. You can render to a thumbnail RTT if you want to because you can't use the depth sense the real geometry might have another depth.

All this is not neccerssary...
The walls can be the walls with materials and depth and all objects can be occluders and occludees. all nodes as well of different scene managers and all....why make this systems beacuse lack of time? Because of SoC licenses?

I say it's bad sport...

If occlusion culling can be done by a scene manager then I couldn't care less about your "plugin" to Ogre or the fact that you don't think it should be done by a scene manager (if I'm understanding you correctly). A scene manager's job is in fact to do exactly that - manage the scene - including what should be visible.
Yes manage the scene but not render it.
Hardware occlusion query is done in the render process not scene manager process.

The plug-in is a render plug-in that adds a first depth pass with hardware occlusion testing.

Surly you not suggesting scene manager render things directlly?

However this project is a bit strange so yeh it might be possible to have scene manager issueing queries and render none wall walls.

Can you all understand what I mean with cheats now? This is one. you have two render your walls twice. And it's not so general, depth pass might not be usefull, so another depth pass may be needed.
.

Lee04
0 x
Ph.D. student in game development

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Sat Aug 26, 2006 11:19 pm

It's not a cheat! It's a way of performing gross high level geometry culling, along the same lines as if you had precalcalated a potential visible set from any particular cell. It's a way of partitioning your scene into logical pieces and then testing what is potentially visible from where you currently are. After passing the test, it pushes it down to the lower level scene manager associated with the cell.

As I mentioned, a scene manager is responsible for visibility. It can use any method it needs to in order to determine visibility, including using hardware occlusion queries. Scene managers are allowed to have custom cameras and scene nodes. That's why you always use the sceneMgr->createCamera and sceneMgr->createSceneNode functions instead of creating scene nodes and cameras directly. If the hardware occlusion queries happen during the render process, that doesn't stop the scene manager from initiating a query and then reading the result the next frame, or however the scene manager wishes to perform this task.

I haven't looked into your implementation, and only briefly at the PLM2's implementation, but if I understand correctly it is done in the scene manager and it seems to be a fairly good architecture. A custom camera and scene node implementation, as well as the scene manager itself, were all that were necessary to get it working.

Perhaps you should just drop the subject because you were doing a lot of arguing without even understanding how Farakon's implementation worked. It was clearly explained and clearly understood by me and others. We know your position on the matter, so lets get back to a real discussion of his system and not yours, okay?

Thanks,

Clay
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Sun Aug 27, 2006 4:46 pm

@Falagard: agree completely. Lee seems to think that we all make newbie occlusion query mistakes like not pulling occlusion queries asynchronously or using early z out (in whatever form). Many of us do, use htese techniques, and the blend of those techniques and their exact form is a question for the scene manager because a cell / portal system will have subtley different needs and implementation details than a CHC terrain system, particular in terms of how render order is derived.

Lee, I don't think you've ever been able to explain or demonstrate to anyone here why your system is 'better than everyone elses' as you seem to believe. Maybe it is, but you've never released a demo publically, or a cogent written article explaining the reasons that anyone else can understand. The sweeping generalisations you make in this thread are completely false, like all other approaches needing to render everything twice, or that occlusion queries are contained in a rendering operation and have nothing to do with scene management. Frankly I find most of your posts in this thread to be completely unintelligible, and it seems I'm not alone. Most of the time you chalk that up to you operating on a different plane of thought to other people, and maybe you're right. But we're not stupid, we understand the topic, we just don't understand you.

If you can explain your system clearly, and why it's so super-awesome, go ahead and do that in another thread, because I'd love to know (just try to form complete sentences and a coherent discussion, please). But please, stop preaching to us like we're daft, and leave this thread for discussion of farakon's work.
0 x

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Post by Praetor » Sun Aug 27, 2006 7:02 pm

First off:

@sinbad excellent use of the word daft. It's been a while since I saw it used in a real way.

@farakon so, each "cell" is pretty much a separate scene manager. Is it actually possible to use the SAME scene manager instance for multiple cells? I can't see why you'd do that, but I guess I just wanted to know. Do you think that maybe multiple-celled buildings could suffer in performance if a lot of scene manager's are used, instead of just one? Is it also possible that your system handles something like a large building using maybe a standard octree scene manager, while being able to look out a window and see sprawling terrain with the PLSM? Being able to seamlessly transition between indoors and outdoors seems like the holy grail of scene management. I've never seen this done. I think Oblivion originally was going to, but abandoned the idea cause it was too hard.

I have to admit I don't fully understand the complexities of this issue, but it sounds very promising.
0 x

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Sun Aug 27, 2006 7:30 pm

Praetor - I'm guessing and hoping that each cell doesn't have to be a separate scene manager, just that it can be a separate scene manager. My understanding from reading Farakon's description was that what you described as the holy grail of scene management is in fact what Farakon has implemented. All the interior cells can be managed by the same interior scene manager, and you can be in a room managed by an interior scene manager looking out a window to outside which is managed by an exterior scene manager.

One problem that I don't think is solved here (and will be up to the developer to solve probably) is the fact that the as soon as you look out the window (can see through the portal that goes from the interior cell to the large exterior cell) the whole outdoor cell is flagged as visible and will be rendered by the exterior scene manager... which means the terrain might continue right into the interior of the house if the house interior intersects or is below the level of terrain.

There are solutions to this - such as cutting holes from the terrain, or even simpler, to have the house above the terrain ... and any areas of the house that are below the terrain such as a basement shouldn't have any portals that can see both the basement and the outdoors at the same time.

Farakon can of course verify if any of my assumptions are incorrect :-)
0 x

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Post by Praetor » Sun Aug 27, 2006 7:53 pm

Perhaps that low-poly occlusion mesh can be used to our advantage here. I understand that the hierarchy goes down into the scene managers, but perhaps there could be a way to query back up into this super scene manager and figure out that the player is indoors, and that the outdoor scene should not be rendered in that area.
0 x

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Sun Aug 27, 2006 8:11 pm

I'm second guessing myself on my last post about having a scene manager per cell now that I've had a second to think about it. I'm eagerly awaiting Farakon's reply, because I really have no idea now.

If a scene manager could be shared across cells then a scene node would have to be associated with the cell and portal/cell visibility routine would actually be setting the visibility of the node. So I'm very confused :-)
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Mon Aug 28, 2006 7:46 am

@Falagard: sorry for the delay, I m away from home. You are right on most of what u said. For the exterior scene, you should cut the exterior cell, this can be a box with a hole in the middle.

I m going to try implementing the list of features below and hopefully by the end of the week, if u have other additions that u feel necessary do tell:

* ability to tag movers as occluders
* portal visibility threshold: do u think we need a threshold for every portal, or all of them share the same threshold?
* Scene manager sharing: share the scene manager accross many cells

Other necessary features are going to be added as well (not necessarly by the end of the week):
* bounding sphere for movers
* SceneQuery
* other few set/get methods
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Mon Aug 28, 2006 11:38 am

Yeh it's not so easy to understand.

I am not suggesting you stay and wait for a query, mearly saying that you say that it OK if the application works,

More or less you are saying what ever works for the application or demo goes..in the name of time, or in the name of whatever.

I think it's bad beacuse if somone can select you application runs with it and make a big project maybe money is put into the mix. They stand to lose beacuse....Someone said they added hardare occlusion and in the end it was not done general anuff so they project they do just goes bust.

Thats how an engine can get a bad name.

I think Ogres RenderSytem should have a render that does the correct thing with early z out and hardare occlusion API to start with.

After all hw occlusion query API is a rendering API...it's a part of OpenGL and DirectX and sholuld be applied inside the inner render loop.

You shouldn't need extra passes to render walls or depth...

Hope I clear this time.
0 x
Ph.D. student in game development

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Mon Aug 28, 2006 1:07 pm

there are things u seem to have missed. The occluder is usually a whole single mesh. Unless u want to sort the plolygons for this single mesh early z is useless. The next thing for occlusion query is disabling writing to z buffer and color buffer when u render the portals, and then again early z out is useless. The only thing where early z out might be needed is when u tag some movers as occluders, optimization is needed then, and might not be so simple.

Your plugin seems to be made for different purposes Lee but mine is for scene management.
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Mon Aug 28, 2006 2:19 pm

Your plugin seems to be made for different purposes Lee but mine is for scene management.
No what you don't see is

Hardware occlusion API for rendering and quering is a RenderSystem thing

While deciding what to test and use the result is the scene manager thing.

CSG brushes makes a good candidate for not drawing the hole BSP when drawing the main occluder. An octree could be used for instance when drawing the main occluder. I your case drawing the hole thing is more efficient if API draw call wise. It's a trade of between overdraw and number of API draw calls, it's depending on the application so maybe you should have a switch for it :).

In big game levels for instance with different houses, streets, steers etc. You can get quite a overdraw.

No infact we did a scene manager like yours 2.5 years a go using hardware occlusion query..it took the natural next step and used mesh hulls for spaces instead of portals allowing the scene manager to coupe with dynamic scene where walls and level is destroyable and changeable.

We did the plug-in so Ogres rendersystem could use hardware occlusion API, so our scene manager would be able to work in Ogre as well.

But before we did that we tried getting Ogre community involved, no luck.

We tried getting Ogre developers at the time to help us implement hw occlusion to Ogres render...no luck. At the time there was not so many know what it was....not so many still knows what it is.
What they seen is the low level API we added to Ogre, but that’s needs it counter part in the Ogre render system to work.

But that hasn't been added which was my hope when I supplied the low level wrapper functions for Ogre.


Still to this day everyone is doing everything but add it to Ogres render system....

Avoiding the issue at all cost, claiming there is no issue because it depends what application you do..... :)

Ogre team can state that it supports hardware occlusion query because the low level functions are in there that I added. What they didn't tell you is I added these because I wanted them or someone else to add and use them as they should be used in the Ogres rendering system....

But no such effort was ever made.

If they added it in all sorts of scene managers could have used it long time a go....

Thats the way I expect open source to work. But no...

Then came the chc approch. And know yours..I bett we have a couple of more sidewinders going past making changes to the Ogre renderingsystem out there. A lot of Ogre users don't actually use the hole render system at all but just Ogre as a wrapper and then they do there own engine.
So they have hopefully put it into there own rendersystems or not.

Where did I get my insights? Well directly from NVidia engineers between four eyes.


So ofcourse when some one in the Ogre community toold me your project was adding hardware occlusion query to Ogre I was quite interested what you would do.

Add it to the render system for real or do a chc kind of thing.


People are so happy with what you do culling portal and so that they don't care about miner details. But then again there bloks like me how does care.

And it's not easy to be alone on a public forum speaking your mind, when no one agrees with you at all. People are more concerned of joining in a group of consensus rather than stand out arguee for something.
0 x
Ph.D. student in game development

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Mon Aug 28, 2006 2:36 pm

now i see what u mean, u want to add occlusion query to the render system, that's logical, actually I thought that we should use occlusion query that way, but then met it in reality. Yes, I think everyone agrees with you to do occlusion query in a transparent way. But till then we have to make it through with what we have. Maybe occlusion query is going to be added soon to the rendering pipeline, but now it isn't. My plugin was about scene management using occlusion query, not adding occlusion query to render queue. The thing is that u didn't mention or give a hint about adding it to the rendering queue or whatever, and I m not sure why you waited till now to do so, shouldn't u tell us about it before SoC even started?
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Mon Aug 28, 2006 3:04 pm

but then met it in reality.
U mean the Ogre team?
Yes, I think everyone agrees with you to do occlusion query in a transparent way.
Yes, it's a dream two work with, but a hell to get working in the first place.
But till then we have to make it through with what we have.
Yes thats why I offered you my plug-in, so you use that would force them later to add it into the render system...

But the SoC license things stops it

Right know you are using a none transpartent approch for instance instead of the transparent one.

Maybe occlusion query is going to be added soon to the rendering pipeline, but now it isn't.
yeh I have made suggestions to the Ogre team but none is good for them can't understand why.

My plugin was about scene management using occlusion query, not adding occlusion query to render queue.
Yeh thats why you shoudn't add it you should just show what happens if you do and use it by borring my plug-in...
The thing is that u didn't mention or give a hint about adding it to the rendering queue or whatever, and I m not sure why you waited till now to do so, shouldn't u tell us about it before SoC even started?
First off I couldn't belive they tell you do do hardare occlusion query as well.
Sense I know it's hard to imlemenet them to renderques.
I got to know this to late and when I did I approched you.

I did mention renderques.... and Ogres rendering sorting on materials.

Well well, we see what it comes out of this...
0 x
Ph.D. student in game development

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Mon Aug 28, 2006 3:30 pm

U mean the Ogre team?
no, I meant the implementation.
Yes, it's a dream two work with, but a hell to get working in the first place.
I have no idea as I didn't try it.
Yes thats why I offered you my plug-in, so you use that would force them later to add it into the render system...
But the SoC license things stops it
Right know you are using a none transpartent approch for instance instead of the transparent one.
I v already said I m thankful, but I wouldn't accept it because of license and it's better like that (keeping it free).
First off I couldn't belive they tell you do do hardare occlusion query as well.
Sense I know it's hard to imlemenet them to renderques.
I got to know this to late and when I did I approched you.
I think what they did is natural, I don't have monthes of experience, and SoC is a program intended to introduce new ppl to opensource projects, maybe later I will be able to implement it. But for now, I m happy with what I have. I implemented the concept with what exists relying on free materials so everyone could use it.

Cheers,
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Mon Aug 28, 2006 4:05 pm

Here we go again. Apologies for getting drawn into this again.

Lee, feel free to snipe at the OGRE team (mostly me) some more over this - I have to have a thick skin to do this job anyway ;).

Fact is, you've never offered your implementation up as open source, or explained it very well so someone else could run with it and reimplement it the way you want. It's perfectly fine to want to keep this stuff to yourself under a strict license, but you have to understand that if you do that, you're on your own in terms of convincing other people of its merits. You haven't managed to do that, through a combination of none of your work being public (not even in runtime form, as far as I know), and because we can't understand what you're on about half the time.

I think it would be useful to be able to schedule the issuing (but not retrieval) of occlusion queries inside the render queues, if it didn't over-constrict the render sequence for people who didn't want to use occlusion queries. It could probably be slotted into the RenderQueueInvocation / RenderQueueInvocationSequence classes, which were largely written because of your requests. So don't tell me I ignore everything you say. ;) But, I still assert though that it's actually deciding what to use as an occlusion test, and deciding what to do with the result, that's the most important thing and that sits squarely with the custom SceneManager.

It's a question of levels of interest. I'm interested in the approaches you used to schedule occlusion queries generically, but I'm not interested enough to either get involved in special licensing deals, or spend time reimplementing it when there are other demands on my time, and other ways this can be achieved (as tuan, lioric and farakon have proved). As far as I'm concerned it's up to you to sell the idea that this is vastly more desirable than the alternatives, not me. If a salesman fails to convince a customer to buy something, does that mean the customer is at fault? Clearly you don't want to contribute the code as a patch, which is frankly all I'd be interested in, not a licensing deal, because I don't consider the benefits to be significant enough to get tangled in that minefield - even though it's almost certainly of some benefit, it's the 'whole package' that matters.

Put it this way - open source features get developed purely because people want them, or want to work on them - it's purely demand led. If this hasn't been done yet, it's because not enough people want it badly enough. Perhaps they would if you produced an absolutely kick-ass demo which knocked everyone elses socks off and showed them why your approach was indispensible, but you've never done that - all we've really ever seen is talk. Everyone else here is putting real code out into the public, to be examined and critiqued on it's merits. Honestly, it really is a 'put up or shut up' situation. ;) We can't continue debating the merits of something none of us has seen. I appreciate the suggestions and license offers you've made, but you have to understand that bundling other people's commercial plugins is not the direction Ogre is going. If you want to convince people, show them why they should buy it. The Showcase forum is right down the hall.
0 x

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
Contact:

Post by Praetor » Mon Aug 28, 2006 6:29 pm

I don't think you can get anywhere Lee with this train of thought. On an open source project if you want something done you can ask for it or do it yourself. If you ask for it, and then complain about how it isn't done "right," the usual response would be to contribute back instead of complaining. Since you are unwilling to do so you aren't going to get anywhere.
0 x

User avatar
farakon
Google Summer of Code Student
Google Summer of Code Student
Posts: 66
Joined: Sat May 13, 2006 6:47 am

Post by farakon » Fri Sep 08, 2006 8:18 pm

I m now in the process of implementing SceneNode cell determination based on bounding boxes, I wonder how the process of updating the bounds is done? What I want to know is if the _updateBounds is called before findVisibleObjects or should I call it myself?
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 2
Contact:

Post by sinbad » Sat Sep 09, 2006 4:54 pm

It's done as part of SceneManager::_updateSceneGraph.

It's not necessarily required to use SceneNode bounds, it depends on your approach. The default SceneManager uses the combined bounds of the nodes to cull, others do not (like the octree manager). However since it's cheap tp compute it's done as part of the scene graph derived transform propagation.
0 x

User avatar
detox
Greenskin
Posts: 103
Joined: Thu Sep 07, 2006 1:13 am
Location: Ohio, USA
Contact:

portals

Post by detox » Wed Sep 13, 2006 1:02 am

This is a very interesting project farakon, and impressive progress in such a short time.

It's my understanding this type of system is used in the City of Heroes interior scenes? Anyone know for sure? I'm guessing it is a somewhat similar system based on various graphic glitches I've noticed while playing. Sometimes the engine gets confused about what is an adjoining cell, and sometimes it's clear where the portals have been placed.

Anyway, nice work, and I can't wait to see how it turns out.

I just started with Ogre myself. I'm interested in converting a 2D tile-based game (written using SDL) into a pseudo-3D game using Ogre for the gfx. On that note, anyone know of a good way to use 3D data from Rhinoceros into Ogre, or of a way of converting DXF files to meshes?
0 x

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Post by Lee04 » Wed Sep 13, 2006 9:01 am

I think it would be useful to be able to schedule the issuing (but not retrieval) of occlusion queries inside the render queues, if it didn't over-constrict the render sequence for people who didn't want to use occlusion queries. It could probably be slotted into the RenderQueueInvocation / RenderQueueInvocationSequence classes, which were largely written because of your requests. So don't tell me I ignore everything you say.


Yes I know you are nice and busy :)

And Ogre is a generic render.
I just whish it uses all the fundamental rendering APIs in OpenGl and DirectX the correct way l in the render. And not leave some basic ones out like the hardware occlusion query, so people have to do hacks to use them. Don't bullet it in Ogres feature list as a feature it if it's not really in the render yet or people won't add it to the render....
I added the low level wrapper so some one else would add it to the render later. Not because I wanted it into the Ogre feature list before that happened. It kind of destroyed my plan at the time and later as well. And every time someone makes the same phony statement I get irritated.

Our plug-in has already been featured years ago in the showcase forum, together with per pixel displacement shader as well I think, which everyone miss toke for a parallax mapping at the time.
0 x
Ph.D. student in game development

User avatar
Falagard
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2060
Joined: Thu Feb 26, 2004 12:11 am
Location: Toronto, Canada
Contact:

Post by Falagard » Wed Sep 13, 2006 1:25 pm

You've never shown a nice demo of your technique, Lee. I downloaded your demo which didn't show anything interesting at all.

Stop mentioning that other people's efforts are hacks. Ogre does support occlusion queries and is open source so if you want to do what you did, which is customize Ogre's ...whatever... you can, and you're even selling your plugin! You're making money off an Ogre project (or trying to). Which makes me wonder, have you updated an Ogre system, such as the RenderSystem or SceneManager? Has anyone released a project using this updated code? Are those modifications to code that is under the LGPL license? If so, aren't I entitled to a copy of that source code under the LGPL license agreement?

Clay
0 x

User avatar
Project5
Goblin
Posts: 245
Joined: Mon Nov 22, 2004 11:56 pm
Location: New York, NY, USA
Contact:

Post by Project5 » Wed Sep 13, 2006 5:25 pm

A long time ago:
Monster wrote:However, I think what you need is a "killer app", a demo that really showcases the power of your technology, not just a rehash of an existing Ogre demo that doesn't seem to benefit from using your technology! If people could download a demo that allowed them to turn occlusion culling on and off and see the benefits for themselves then maybe that would attract more potential buyers?
Lee04 wrote:The free demo version starts in off mode then goes on and then turns off after some time. So the effect would be noticable.
The developer version works this way as well, but it starts faster and works longer.
"After some indeterminate time" is the problem here, this needs to be user toggleable if you want to impress the performance gains with the demo. I'd really like to see a demo with "Hit F1 to toggle the plugin" so I can see the gains with it.

Then:
Lee04 wrote:In the upcomming demo we will be showing you a simple demo using this shader and hardware occlusion query where you can turn hw occlusion on/off and see the FPS difference...just from this basic rather small shader with only pass....

A 6800 Ultra running Ogres shadow demo with a 600 FPS goes down to 80 FPS with this shader applied to the floor plane in the shadow demo.
Great, I thought, here it comes. Then the final post in that thread:

Lee04 wrote:Someone requested a demo showing the benifits of hardware occlusion query.

NVidia has released the source (openGL) for a nature demo that uses hardware occlusion queries.

http://developer.nvidia.com/object/nature_scene.html

It allows you to enable and disable the the queries to see the FPS differance.

Note: be sure to stay close to the ground to get get a fair sence of the differance.

The demo also enables you to see the bounding boxes it uses.

If you like to evaluate our hardware occlusion query solutions for Ogre PM me.
So to demo your plugin's advantages, we're pointed to a demo that Nvidia made?

That's why people keep saying that your demo wasn't impressive. I'm still looking forward to the demo version that you said was coming :-)

--Ben
0 x

Post Reply