Dirk Reiners wrote:

>    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.
>  
>
There are still a lot of discussions to have here, but I agree that 
getting it done sooner rather then later would be a good thing. The more 
I see the implementation details in OpenSG 2.0 the more I realize just 
how hard of a problem this is to solve well.

>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.
>  
>
My models will be static. I don't think it will be hard for me to get 
things working as long as I have some support if I run into bugs in the 
existing feature set.

-Allen

>    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
>
>  
>


-------------------------------------------------------------------------
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

Reply via email to