World: r3wp

Maxim, all demos run fine now.

thanks.  Andreas told me he was reaching 70fps using the simple tree 
demo running wine on linux!

closer to 2-5 fps here, but probably due to software OpenGL

(strange that it runs now, when I was warned before that OpenGL wouldn't 
work)

the heavy tree is quite hard... the torus should be real-time even 
using software mode.

also when first showing the window, the view area is only in about 
the upper left quarter of the window. a resize solves this.

I get between 5-10 fps on the torus. I suppose virtualbox doesn't 
do this stuff very well.

wrt resize, yes that is on purpose.  it allows me to test events 
within and without the opengl.

its possible wine allows some of the rendering to find its way to 
the gfx card.

ok

ok, next step: modeling dialect :-)

and yes it is strange that it works now and didn't work before!  
I didn't change any of OpenGL code, though I had a serious memory 
corruption issue, so its possible that on your system, that translated 
to some bogus system call.

it has been behaving strangely just yesterday (openGL issues) and 
today (network flakey), so I'm not even sure it will keep working. 
:-)

what is the .r3d format like?

hehe.  if you look at the demo files, you will see how to specify 
a polygon primitive... its dead simple... a list of vertex... and 
a list of faces (which are indices to the vertices)

look into the torus... its a rebol loadable data file.

the same as the commented out primitive in the tests.

It would be wonderful with an actual dialect:


view [my-torus: torus scale .2 rotate 45 material [specular: blah]]

yep that is how it will be... its already close to a dialect.  I 
just need to add more attributes.

btw notice that I included your last release of the r3_gui.r3 in 
the cgr-apps to make sure I stay forward complient... though you 
may want to do a diff on the version included and yours in order 
to patch crashing events when they originate from a gob which isn't 
a face.

ok, but I suspect many changes and additions are coming. I'm not 
sure if it will be a problem for you.

I'll also add a few default primitives like sphere, cube, teapot, 
etc.

how do I find fps for the Torus demo?

for me it won't change anyting as long as you can retrofit the event 
stuff I am "fixing" as I encounter them..

you count the number of refreshes in a second... printed in the console 
 ;-)

so, it simply renders into a GOB? can you make a demo where it's 
integrated between some styles?

pekr, on windows it shoudn't go beyond 60fps because of timing issues.

henrik yes.  the openGL CGR use the "container" rendering mode which 
allocates a windows control from scratch and adds it to the window.


then when you call show, it gets notified of the change in size and 
automatically updates the control and gl viewport & camera

notice that I do not call show on it in animation.  I call refresh, 
which bypasses view and makes it *much* faster.

henrik, I'll wait for the next release of r3-gui.  I wasn't able 
to launch the style browser.. it gave some error.

cool, I'd like to see a demo with styles, if possible. that will 
be a good indicator of real-world viability of the extension.

Maxim, I'll build a new r3-gui.r for you.

ok, I'll try it out tomorrow.. its 5AM here... got to go get some 
sleep :-)

if you can do one thing to help me.... make a style which doesn't 
allocate any of the gob type data.  (color, text, draw etc) so that 
when you print the gob its basically a none gob.

ok, cool

I use the none type gob as an indicator that it *might* be a cgr, 
this allows me to quickly check any face without it being to slow 
to retrieve the CGR internal data.

I hope Carl and I will agree on some definite way to allow some kind 
of custom data extension.

I need an extra pointer in the C gob structure.  cause basically, 
all the renderer data is gob-centric... right now I'm allocating 
an array and iterating through it which isn't very optimal, though 
this makes it 100% safe in the current host-kit.

Two consecutive runs cause following:

>> do %opengl-complex-tree.r3
Script: "Untitled" Version: none Date: none
Script: "Untitled" Version: none Date: none
IMPORTING LIBS
CANNOT SET CGR LIB MORE THAN ONCE (cgr_opengl.dll)
====================================
OpenGL CGR initialization:
registering polygon primitive
register-primitive() [
        valid-prim?() [
        ]
        cgr-name() [
                OpenGL
        ]
]
====================================
Script: "Untitled" Version: none Date: none


then it stops for a while, then it shows window, and outputs other 
stuff to console ....

Pekr, profesional way is to use tool like: http://www.fraps.com/faq.php
I have 60fps for torus example

which is the max allowed by wait 0.01

yes pekr... as noted in the help message, you can only import the 
cgr lib once... if you do a script which already imports the cgr 
lib it will complain.

if you are showing the tree-heavy, its a 170000 vertice model which 
ways 15mb on disk and 50mb in ram !

on my system tree-heavy averages 8fps at any window size. 


the reason its this slow is that I'm not using any kind of smart 
opengl video ram caching atm.  this will obviously be done in time... 
for now I still need to implement things like a real camera primitive, 
lights and materials.

I suppose the file format could use some compression. Or you could 
make an .obj importer, which I think already exists for R2.

With the heavy tree I have 20fps but I can hear strange sound from 
my notebook.

max - why don't you use more precise wait?

oh... if there is an .obj importer I'll use it.

yes oldes,  I am hearing it too... I have NO CLUE what that is.

possibly the gpu fan is getting a little hit at every frame.