direct acess to jogl and lwjgl

Engines, Libraries and Tools Xith3D Forums
#1

Hi

yeah - I made a new thread for this topic as Will suggested. And now I will post an idea of mine ;D

I think the problem splittes into two different sections:

[shadow=green,left]1.[/shadow]
telling the renderer not to do things (like glClear() )

[shadow=green,left]2.[/shadow]
We could make a Native-Wrapper-class which we can set in e.g. com.xith3d.render.RenderPeer.setDirectAcces(Wrapper w);
This Wrapper got methods that get called, when the rendering reaches specific steps.
Such a method could look like this:


public executeAddOn(<Parameters describing the circumstances of the position in the rendering process>);

These parameters could be an integer describing the position of the rendering process (e.g. init_done) and then maybe an allround parameter as type Object, whoose type is dependent on the position.
To get acess to jogl/lwjgl/(other not yet existing renderers) we simply could write methods that return instances needed for the direct acess. This will ofcourse make these Wrappers not anymore open to any other renderer, because then new functions would have to be added. But when such a renderer gets added to xith, we could simply change this wrapper. If it is some homebrewed renderer, which we don’t want to add to xith-core because of whatever reasons, it could simply get extended.

We could also make a major design change and put the rendering stuff also in such a Wrapper and then also have a list of Wrappers that get executed, and where it is easy to turn Wrappers on and off. This would somehow unite section 1 and 2 ofcourse :slight_smile: And there will be probably problems I don’t wan’t to think of for now :wink:

So, what do you think?

Arne

#2

Not a bad idea - split the renderer up into a set of blocks that you can customise. Fortunately it is mostly like that already, all that’s needed is code to do the switching part (not that this is easy).

Maybe we could have something like a “RenderProfile”. I’m guessing with multiple-passes people will generally use two or three set configurations (i.e set of Wrapper off/on states). So if they can configure these “profiles” ahead of time, and then just go - “render profile 1”, “render profile 2”, that could work.

We should come up with the use-cases for feature that require multiple-rendering passes. Here’s some:

  • Render to Texture
  • Mixing parallel and perspective projection
  • Motion Blur

I definitally don’t think we should rush this feature. It is one that Xith3D definitally should have, and we should take care to do it well and get it right the first time. I would like to hear Yuri’s suggestions on this topic as I know he has put some thought into it previously.

Cheers,

Will.

#3

[quote=“William Denniss,post:2,topic:24522”]
Hello!!!

+1000 :slight_smile:

Endolf

#4

I have filed an issue so that this thread and its ideas are not forgotton about: https://xith3d.dev.java.net/issues/show_bug.cgi?id=101

More discussions will be needed :slight_smile:

Will.

#5

Even if I don’t have the use of such a feature right now, I think it’s a good thing to do.
Just a thought : “Really simply, why the Clear() and SwapBuffers() command are automatically executed ? If we could do this manually, we would have a temporary solution, huh ?”
And another thing about optimization :

  • Is any form of culling implemented in Xith ?
  • If not, is it possible with the current architecture to implement e.g. Occlusion Culling ?
#6

As arne points out it is possible to disable the “clear”, at least in JOGL.

For those following this idea, make sure you read (or subscribe) to the issue in IssueZilla. Yuri has made some good points.

Will.