Allen Bierbaum wrote:
> Marcus Lindblom wrote:
>   
> I like the reorg.  Now I just need time to read through it all and 
> comment/edit/contribute. :)
>   
Thanks!
>> Ok, so we have (in order of complexity and closeness to code):
>> - tests
>> - examples
>> - tutorials
>> - demos
>>
>> Tests should go with the source, yes.
>>
>> I could live with examples in the source _if_ they were properly 
>> referenced in doxygen and on the website.
>>
>> Tutorials as they are now (move examples over to tutorials instead?)
>>
>> Demos - not in dailybuild (separate pack there), but include in the 
>> large point release packs?
>>     
> I consider demos and examples to be the same thing.  IMHO demos are 
> useless unless they are in the dailybuild so we can point to them each 
> time a new feature comes out.  There may be some really advanced demos 
> that are separate from OpenSG but I think those would be few and far 
> between.
>
> For example, I think we should introduce examples like:
> - Shadow method explorer.  Loads up several scenes and allow the user to 
> switch between all the shadow methods
> - Occlusion culler/tester.  Loads up a model with occlusion culling 
> enabled and shows some stats about how occlusion culling is working
> - Multi-stage rendering: Examples of several scenes with multi-stage 
> rendering.
>
> The examples should show how to use the code and should demonstrate the 
> capabilities of the code.  Thus the examples serve two purposes: 1) 
> teaching people  2) demo to promote online to show off the new features.
>   
I was thinking that Demos could be large (5-20 megabyte each) depending 
on data set, to that's why I wanted to avoid having them in the 
dailybuild (which Dirk has pointed out is perhaps too large already)

But it depends on definitions. We have just unit-tests and 
examples/demos/tutorials. Then we need to reach consensus on where to 
put that code and how to document it.


>>  
>>
>>     
>>>> (Is it possible to record from OpenSG? I don't think so, but there may 
>>>> be experimental code for it. Ought to be fixed and perhaps even 
>>>> automatically generated? .. start examples with a '--record' arg?)
>>>>  
>>>>      
>>>>
>>>>         
>>> We have a FileGrabForeground that can save every rendered frame to a new 
>>> file. We also have some contributed code from Mathias Gumz in Contrib 
>>> (VideoGrab) that uses ffmpeg to directly grab to video but I've never 
>>> gotten around seriously testing it.
>>>    
>>>
>>>       
>> Yeah. Hm. I ought to contribute my 'hiresscreenshot' code. I got it to 
>> work pretty good (although it needs some improvement to be fully general.)
>>  
>>
>>     
> I would like to see this.  I have been looking for an easy way to get a 
> highres screenshot to make some posters. :)
>
>   
>> How about mentioned the Contrib-code on the wiki, as stuff that works 
>> but could use some 'serious testing' ?
>>  
>>
>>     
>
> Sounds like a great idea to me.  That way it could be documented a bit 
> and people could provide feedback through the wiki.
>
> -Allen
>
> PS. Marcus, if you don't slow down I won't be able to even have time to 
> reply to all your e-mails. :)     I love it, keep up the good work.
>   
I was bored over the weekend. I need to get a life. :)

Now I'm back working, going to London today for three days, then it's 
band practise, workout and driving home to my parents over the weekend, 
so you'll definately have time to catch up. :)

/Marcus

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users

Reply via email to