Hi folks,
Gerrit Voss wrote:
>
> my answer would be it does not have to. The basics are done, I'll try to
> get a least a small test for CPtr MT rendering done so if somebody wants
> to make the decision FCPtr or CPtr and change the interface accordingly
> it should be possible ;-) Most of my opinions and concerns are known
> anyway ;-)
Allen Bierbaum wrote:
> I guess that means that Dirk knows them. I just wanted to know if
> there will still be on-going discussions about this. My take away
> from this thread is that we will probably delay these discussions (but
> they do need to happen ASAP). Do you agree Dirk?
I would like to get it done ASAP, too. My hope is that we can get rid of
a lot of complexity in the Pointer arena by deciding on using something
simple like CPtrs, and I would be happy to spend whatever time I have on
changing interfaces.
Gerrit Voss wrote:
> Even in hiding I want to keep my work public enough that it won't be a
> big surprise at the end and that it does not collide with other things
> going on. I basically want to focus and blend out all the other distracting
> elements (like ptr stuff, collada loader, ...). And I won't stop all coding
> ;-)
>
That's reassuring. ;)
> As you two are most likely use/work on the same parts right now I hope we
> could keep
> ourselves somehow synchronized ;-), that is one idea behind the public git
> repository.
> And there will be intermediate merge points were I push things into the svn
> so it
> is easier for you to use and follow.
>
OK.
> As said discussions around the rendering backend are and will be always
> welcome ;-)
>
> The stage stuff should be kind of stable for the moment, though the usage
> is not very intuitive, the stages, except the initial one are executed in
> reverse creation order (interestingly the svn has creation order execution
> but this is wrong). Let's see if I can come up with a clever way to get
> around this problem ;-) Overall there are one or two problems left right now,
> currently
> only cores can create a stage, but it might be interesting to have
> 'materials' do so
> too. Another one is having finer control over stage execution (e.g. on demand,
> once per frame, every time traversed). So hopefully most of the stuff will be
> additions
> which don't break what is already there. There will be some warning time until
> it reaches the svn repository and I'll make sure you know before it shows up
> ;-)
>
I haven't looked at the code, but I don't think dependency would be a
big deal. I assume you just have a vector of stages that you collect on
traversal and that are executed in whatever order they're found?
> My immediate focus will be more on overriding material (mainly shader) parts.
> Which is
> needed if you want to do shadow maps or early z passes and the vertex shader
> affects
> the geometry. Basically you want the vertex stage results while at the same
> time avoid
> executing expensive fragment shaders which should be replaced by the cheapest
> possible
> variation. Which will be followed by looking into the more general dynamic
> shader composition
> problem. These are the main two areas I need to get a rough idea of before I
> can write
> something ;-).
>
I see you needing complex stuff for shaders that change geometry. Allen,
do you need that? I thought your models were static, so that a simnple
total override would work for you. That's easy to do.
Dirk
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
