AltME groups: search

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

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

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.

Maxim, it works for me now, cool. Some notes:

-The usage/interface seems to me too clunky. Better would be something 
like:
append win make gob! [
	offset: ...
	size: ...
	data: context [
		renderer: 'opengl
	]
	draw: [trinagle ... sphere ... whatever] ;your 3d dialect here
]
And that's it IMO there is no need for other 'bloat' around.

-Since you are proposing the CGR philosophy:

1.is it possible to use more than one gl-gob ? I tried just a quick 
attempt but it failed for me.

2. is it possible to compose normal gobs together with the gl? I 
had no luck with this either.

Regarding the performance:

I don't think there is anything to comment at the moment because 
you are just using the raw/built-in OpenGL abilities (same stuff 
we did with Ladislav and Cal 5 years ago in R2). So talking here 
about FPS or number of polygons has the same information as saying: 
"I have older/newer gfx card" The fps is not related to the current 
code...everything is just direct HW executed calls.

in the current stat of the host-kit and rebol architecture in general:
---------------------------

1) I cannot use data, since that is being used by r3_gui.r3 so it 
has in effect become a reserved word which we can't use.

2) if I use gob/draw, then I am in fact trying to hijack the meaning 
 of  draw gob... an AGG draw block.

3) the current gob! API is very limited because it was shrunk to 
handle a very specific use case.  I can't really play around with 
anything cause it just breaks up real quick (I tried).

4) the CGR API doesn't have a scene dialect yet, but that is just 
high-level use.  if you look at the code, its 4 lines of code to 
have an openGL high-rez model viewable in a window... I hardly consider 
that bloat.

5) using commands to manage a real life scene with several thousand 
animated, deforming objects and scene changes, is a nice dream. it 
doesn't work in practice since just managing the thousands of blocks 
this requires ends up eating a way a sizeable part of the CPU and 
ram.  

6) data marshalling is heavy, REBOL datatype access is heavy, datatypes 
use A LOT of ram, and the GC is extremely intrusive,  CGRs solve 
all of this while still making the high-level interface easy as pie.

7) primitives are more than just dead weight they allow direct access 
to/from rebol and the CGR itself.  they are the *low* level interface 
which can be used directly or directed by the use of a dialect later. 
  the difference from AGG is that these structures are persistent 
for many reasons, which will be much clearer in the future.

8) CGRs are not only for 3d graphics, but for any rendering.  primitives 
are a generic container to access/construct any rendering engine 
in the same way. ie. all CGR will use the same core cgr dialect.

9) the code does support multiple cgr gobs, but it might have bugs... 
I didn't even try it yet... I was busy getting this stable and released 
asap.

10) The opengl-cgr currently doesn't integrate into the view compositing, 
since that instantly *kills* rebol.  I mean... totally.  500x500 
a 30fps... = 100% cpu just blitting graphics (not even opengl rendering). 
 opengl-cgr uses the container mode, which actually uses up a sub-window 
(like every single construct in windows) and allows system double 
buffering in that area.

11) CGRs are compatible with all other gobs, though they must be 
built to support the internal gfx pipeline by using the compositor 
or image rendering modes.  That is how I started and it was quickly 
obvious how un feasible it was for opengl.

12) rendering performances ARE very implementation specific. using 
show instead of cgr-refresh on the display loop will show a performance 
penalty anywhere from 10-1000% (depending on nested gob depth & size). 
 If I didn't create internal data for the models, the large tree 
example would run much slower, if I used commands to call every opengl 
call in the large tree example, it would likely take several seconds 
a frame even with hw support.

in the future:
----------------------------

-there will be (hopefully) a small number of changes to the host-kit 
which will allow 1, 2, 3 to be resolved in a more natural REBOL feel... 
this current implementation actually highlights those needs and you 
where quick to point them out  :-)

-concurrency requires a bit more sophisticated structures to prevent 
locks, using the current design I solve some (though not all, yet) 
of the requirements for true concurrency, and this directly relates 
to issues and/or decisions in 5, 6, 7 & 8

-my goal is to have a high-performance rendering engine which isn't 
bound by any inherent design incompatibilities between REBOL and 
optimised native code, especially if the engine has access to hardware 
in parralel to the interpreter.  when i look at all the current games 
out there and they slow down even using only compiled code and sometimes 
not even really complex scenes, I don't want to fall into the trap 
of adding an additional layer of slowness which is to have the interpreter 
doing the renderer's job.

-I'm not trying to make a "cool" rebol plugin... I am trying to make 
an engine which is optimisized to run within REBOL.  the idea being 
not to help out rebolers per say, but to attract people with rendering 
needs TO REBOL because it has a high-perfomance engine *built-in* 
to which you can graph any actual renderer (DX, OpenGL, video frame 
buffers, etc).
-did I mention I want to make an AGG CGR ?  ;-)

ati always had less than optimal opengl support

Hey Maxim, just a quick reply...


re 1) IMO that is not good argument. You can use GOB/DATA. It is 
really easy to change R3GUI rather to change GOB datatype.


re 2) Nope. There is no problem to have the current GOB/DRAW dialect 
for 3D commands. The current DRAW is completelz flexible and can 
be enhanced. Also if you are proposing abstracted way for 'renderers' 
then it shouldn't matter if you are rendering 2D or 3D objects so 
no need to have different dialects just because of 2D or 3D behaviour 
(see the OpenGL api, it is also mixed)


re 3) not sure what you are missing on the GOB! datatype..Can you 
clarify?


re 5) I disagree here: the 3D dialect is way to go. It should be 
possible to do a direct commands calls for simple things and use 
vertex arrays and other advanced features for bigger things. I don't 
see any problem why this couldn't be done by command dialect.

re 6) to 12) and the rest:
I'm not trying to make a 

cool" rebol plugin..." - so I hope you won't propose this Carl to 
put into the official HostKit distro :-P

The more you talk about your design the more it looks you are missing 
the point of Rebol need for HW acceleration in more generic sense. 
Don't take it personally, but your approach looks like just yet-another-opengl 
binding extension that every other language have. Until that I thought 
you are planning to do it in a more 'rebolish' way but nevermind, 
at least it is clear now. In any way I wish you good luck with your 
extension! ;)


BTW I think It's time to dust off my OpenGL accelerated R3 prototype 
soon... http://cyphre.mysteria.cz/tests/agg-hw.png(And it will work 
on *all* gfx cards made in the last 5 years ;))

I've used this card with a bunch of other 3D demos and with Processing 
(processing.org) and the OpenGL support seemed to be very good - 
must be something specific to the way you set things up, I would 
think

Adrian you are having a very strange problem.  the actual OS and 
opengl code being called is textbox 1.1 OpenGL  I will try to look 
into it, though with the little I've seen the 5xxx series ATI cards 
do come up often has being  "troublemakers" in OpenGL dev, though 
by all accounts the 10.10 drivers seem to cure problems for most 
users.


now I'm not downplaying that its something in my code, its possible 
there is a little something to add explicitely to make your card 
work which is done implicitely on other setups...

if you don't mind I'll use you to test anything I can find.  you 
are at the opposite end of my setup,  mobile nvidia card running 
on 32 bit xp.

its a brown torus:   http://www.pointillistic.com/open-REBOL/moa/files/opengl-torus.png

%opengl-test.r3 ran fine.

%opengl-simple-test.r3 crashed after a few seconds:

@** Script error: cannot access window in path event/window/data

** Where: all -apply- wake-up loop -apply- wait forever catch either 
either -apply- do
** Near: all [
    obj: event/window/data
    obj: select obj 'handle...

Same error for complex tree.


Happened on torus too, then I figured it out. The error occurs if 
I move the mouse over the animated area. Other than that, it looks 
very cool Max.

gregg, that looks like an older version of the distro... the new 
files are:
opengl-torus.r3
opengl-simple-tree.r3
opengl-complex-tree.r3


also the error looks like something I patched in r3-gui.r3 not handling 
data-less gobs... did you update/change your r3-gui.r3 in the distro?

just tought I'd post this little code snippet for fun....


here is the smallest running opengl application I've ever seen  :-)

rebol []

import %opengl-cgr.dll 

win: make gob! [text: "GL_API TEST" offset: 500x50 size: 300x300 
]
append win box: OpenGL-Gob [size: 300x300]

make-primitive box 'polygon [shape: [vertices [0 1 0  -1 0 0  1 0 
0] faces [ 2 1 0] ] changed: [shape]]
view/as-is win

the current version handles multiple 3D view ports and interactive 
dragging of 3d gobs while they are being animated with practically 
no performance loss a part for the 2d gob handling.  I'll check out 
Cyphre's OpenGL tests so see how they can be integrated with CGRs 
so that the complete solution is hardware accelerated.

- MAJOR ANNOUNCEMENT -  Custom Gob Renderers :  prototype released


After weeks of work at various levels, here is the first prototype 
release of my R3 host-kit running OpenGL in HW.

http://www.pointillistic.com/open-REBOL/moa/files/r3-cgr.zip


I updated it to A109 this week-end, I also completely rebuilt the 
file structure so that all of my tools are outside of the host tree.

only the actual host-code patches remain within the host.  the distribution 
includes compiled versions as well as the latest R2 2.7.7 unreleased 
patch.


note that the current OpenGL CGR is not currently very programmable 
a part from giving it polygons to view, you can't change anything.

the view will rotate by 1 degre everytime you call show or refresh 
on it  (so it can be used for model turntables).

resizing the window resizes the view.   notice that full-screen doesn't 
affect rendering that much.

open the readme file for more information


also note that the current geometry engine auto-calculates surface 
normals using face normals, so you'll have a faceted look.

next release I'll add support for vertex normals which will allow 
smooth shading (at no cost).


please reply in ann-reply, and report any problems you may have... 
I'll fix ASAP.Custom Gob RenderersCustom Gob Renderers

maxim that's like if i was asking you to do 3D secenes in XML format 
because hey man i have thet vid xml-opengl rendering black box that 
will do the work for you but hey you don't have any control upon 
the rendering engine

OpenGL, etc.

I'm against changing the name for several reasons:


- The name is established. It takes years to re-establish a new name 
to gain new momentum. Carl's company name needs to change as well.

- You need to relate REBOL 2 with <new-language-name>. This requires 
effort and you'll have to waste a long time explaining this fact.

- There are already too many *-script languages out there, which 
makes AltScript less distinctive. So, is it a Javascript or Applescript 
derivative or what?

Downsides to REBOL:


- The name is overused, which is why there are people against the 
name.
- Pronounciation problem.
- Pointy-haired boss problem (REBOL? REBEL? Hackertool.)
- REBOL is sometimes confused as a COBOL or ALGOL derivative.

- Had REBOL been named AltScript in the beginning, there may not 
have been a problem, but also no distinction.

Suggestions:


- Tone down the use of the name. Use the name as for a technology 
engine, rather than something end-users will confront, like DirectX 
or OpenGL.

Paul, if you've got any questions, I've played around A LOT with 
the install instructions, since I now have a solutions with 3 projects 
and inter project dependencies...


its the first time I really use visual C, so it wasn't obvious to 
begin with, but I do understand most of it now.  it took me a few 
hours to get this new setup working with the host, the extensions, 
my OpenGL extension and the callback thing.

I've replaced all the paths by using the various $(...)  macros.

Perphaps next spring - official launch of R3.1, View/OpenGL, Dual 
licensing, HTC, BlackBerry adopting R3, etc. - good stuff ahead :-)

hi all, I am currently building a wrapper for the OpenGL / GLut libraries 
to allow R3 apps to access OpenGL natively.

MILESTONE !!!  I've got an OpenGL window up and running... called 
from within REBOL  3  :-)

when Carl adds a few little image! enhancements to the extension 
API, I should be able to use a rebol image! as the interface to get 
the OpenGL render into rebol, using R3 view.  If memcopy works, then 
it should be VERY fast ( a few hundred images/second AFAICT)

the goal is to have an OpenGL gob :-)

first step is to have an image! which is updated from the OpenGL 
rendering using high-performance memory copy functions from the C 
side..

woot.. this R3.. now I got to learn C, OpenGL, etc.. 8))

Maxim, I'm sure Carl will love it, if you can provide the same underpinnings 
for VID via OpenGL as through the current engine.

I also need the OpenGL performance for a huge art project of mine 
which composites thousands of pictures.

The first REBOL natively Generated OpenGL hardware accelerated graphics. 
    :-D

http://www.pointillistic.com/open-REBOL/moa/steel/R3-OGL.png

At this point, providing the full capabilities of OpenGL to REBOL 
seems trivial, once the image! improvements are added to Extensions 
API.


Some form of callbacks would also allow us to use a different window 
manager than VID (which would make it faster, since we wouldn't need 
to convert to rebol bitmaps at each frame).

OpenGL is display agnostic.  you can render stuff in any perspective... 
or none, if you want.

The only issue is that some devices might not yet have an OpenGL 
devide installed... smartphones, for example.

IIRC there is a standard called miniGL which is a subset of OpenGL 
specificaly designed for smaller devices... it should be compilable 
on anything, even if you don't have hardware 3d AFAIK.

OpenGL really is on every serious OS in any case, and the standard 
is very well supported, so that if you target a minimal version of 
OpenGL, your app will be pretty much the same on every OS...

but my OpenGL extension is not to replace view.  Its for gaming, 
and a totally new GUI experience...

but Glass will be built exclusively using OpenGL... its going to 
be vastly superior to AGG in what it can do.  never mind pixel details... 
we will have millions of concurrent objects on screen all in real 
time.

I've got impression, that OGL is slowly dying, and feature lacking, 
in comparison to DirectX?


I don't see that. All *NIXs use OpenGL. OS X GUI is based on OpenGL. 
Playstation 3 use OpenGL (PS1 and PS2 used a proprietary Sony API).

From http://www.opengl.org/

The Khronos(TM) Group, today announced OpenGL(R) 3.2, the third major 
update in twelve months to the most widely adopted 2D and 3D graphics 
API (application programming interface) for personal computers and 
workstations.

It seems, OpenGL is growing.

AFAIK 2D on openGL is just the fact of using a flat camera (orthogonal 
perspective) with a camera looking straight down.

When using a Mac, you look at an OpenGL output. If you use the zoom 
function, there is a key combination to put anti-alias on/off. If 
it's off, you see the correct pixels, as there is in the drawing 
(bitmap). But you're right, if you put in anti-aliasing and other 
effects, it can look different on different hardware.

you can simply do a block to struct conversion within the C layer.


the extensions docs show how to read and create new blocks, with 
working examples... you just need to continue from there on.


googling how to connect to a dll in real time will give you examples 
in C, but many dll's which are distributed as tools also come with 
their equivalent static .lib files so you might not need to do a 
run-time link to the dll.  OpenGL, for example came with both.

the OpenGL,  GLut lib, for example, has its own windowing system. 
 so any application can VERY easily create OpenGL apps which respond 
to keyboard mouse and window events.  its ported on all OS, so your 
code runs just about the same everywhere.


If R3 had callbacks, my OGL GLass engine will be ported to all platforms 
without any extra effort.


GLut might not have all the fancy events (I haven't gone over it 
in detail) but its a good basis to develop, being so easy to use.

the most interesting feature: "Currently OGRE runs on Windows, Linux 
and Mac OSX using plugins to drive the underlying rendering API (currently 
Direct3D or OpenGL). Applications use OGRE at the abstract level, 
thus ensuring that they automatically operate on all platforms and 
rendering subsystems that OGRE provides without any need for platform 
or API specific code."


and its open source, and the quality of graphics is quite impressive.

Ogre is probably the most complete open source scene engine, which 
can use both OpenGL and DirectX.

just the fact that you can retarget the whole 3D engine to direct 
X, OpenGL (or another if you wanted to do so) is really impressive.

Apple is moving rapidly to LLVM because they can't get the GCC project 
to cooperate. They already use it for iPhone development and OpenGL. 
Having a path to get to LLVM would be a good thing.

PPC to x86 transition. x86 to x64 transition. OpenGL emulation on 
old video cards that don't support new features. Instruction set 
independence for the iPhone. Objective-C support in the front end 
that can be integrated with their development tools without license 
restrictions. A development commuunity that will accept their patches. 
The list goes on.

I did a few tests loading up OpenGL/GLut and it worked without a 
hitch... waiting for Carl to add a few features before I can continue.


screen shot of a rotating cube http://www.pointillistic.com/open-REBOL/moa/steel/R3-OGL.png

I already found a way to make callbacks extension callbacks in the 
current host distribution, even if nothing in the current rebol native 
code supports it  :-D


will be testing this out tonight and will report on this... I hope 
my idea works.  this would reactivate the OpenGL project along with 
other stuff on the backburner.

jocko,  yes and no.   ;-)  


Glass is going to be rebol code only, but its going to be based on 
rebogl, the OpenGL extension I am currently working on (as I write 
this).  Rebogl its going to be an evolutionary process, starting 
with simple high-level pre-defined primitives and colors and then 
will get more and more customisable (deformers, animation, textures, 
programmable shaders, etc).


I am still not sure how the Glass engine will evolve, but there is 
a good chance that it will be based on the scene graph technology 
I am working on for the Scream game engine.  This has the benefit 
that Glass can be used to build the interfaces within the games themselves. 
 But it most definitely won't require you to load a complete  (and 
inherently complex) 3d world manager, just to build a window with 
a form.  if possible, I'd like to have window masks, so that the 
3D forms can actually live like 3d models direclty on the desktop... 
so some of the nice 3d feature isn't wrapped within an OS window 
border.

brian, yes we can add our own devices... in fact, it seems quite 
easy, and I will probably be adding a DB trigger device within a 
week or two.  :-)


the thing is that there aren't any exposed or documented *native* 
hooks from the host into the core... 


so far, I've got a callback library (called wire) working which executes 
rebol code in global context using the Reb_Do_String() r3lib.dll 
exported function  :-)


now I just need to use that library within the extension and see 
how it goes... the moment I have *something* which works... I'll 
stop improving the hack... from there on, I'll just work on the architecture 
of the caller and callee, to see how we could make it simple and 
easy to setup, from the extension and within the application using 
that extension... generically.


the code in between can change completely, it wouldn't actually change 
the extension or application code (that's the idea anyways)... just 
a few includes and headers which map how to link to the callback 
system.  I'll also try to build a device, just to see how that can 
be used instead of callbacks... but I still need to use a callback 
from the extension in order to access the host... so for now my hack 
is essential, whatever I do.


in this case, I'll be dispatching the GLUT events within the rebol 
using this architecture... I should have an interactive OpenGL window 
by tomorrow... crossing my fingers.


for now I am busy rebuilding my old OpenGL project within the new 
cleaned-up MSVS solution I've been working on for 2 days now... there 
are soooo many properties, its scary and long to setup... especially 
in this setup where there are several interdependent projects within 
the solution... but now, at least, when I change stuff at any layer 
and build, it builds all the stuff correctly in one step...

I successfully used the OpenGL extension with a host I compiled myself 
 :-)

I know have added callbacks to extensions using a little hack with 
an intermediary dll I built, loaded by the host and any extension 
that needs to run rebol code.   so its fun to know that in the end... 
we already have ways to tailor the executable to what we need even 
when it officially doesn't support what you need.  :-)


obviously we can't do everything, but this little test is already 
nice.  right now I execute code when the OpenGL window is resized....

I will be adding events for mouse clicks and keyboard presses, so 
I can start interacting with the 3D rendered stuff.

yes... R3 is a completely different ball game than R2    :-D

yay!  real event model in place and functional for the OpenGL extension... 
its not a permanent solution but it will do for now.f


now the tedious job of creating stubs for a few hundred functions 
begins!


and hopefully by next week the first applications to show this off 
will be demoable  :-)


currently, including callbacks which create an object at each refresh, 
I can't  resize the window faster than the engine can redraw it (up 
to 1440x900, in 32 bit color, with a few shaded polygons ) , and 
this includes hundreds of lines of rebol being printed in the DOS 
shell.

The main thing: linear command evaluation blocks. The replacement 
for the delect method.


Once that's done, I'll release View, but only with the windowing/event 
system, not rendering... then, Cyphre can bring the rendering method 
back online as his time allows. (Or, you can do your own in OpenGL 
if you feel so inclined.)

The code includes some new host source files, for example to handle 
windowing and the related events.


Although this release comes with the AGG sources needed to do the 
build, note that these sources are pre-GNU versions, so are a bit 
older.


In addition, I suspect Maxim or someone may want to try creating 
an OpenGL version.


Soon, we plan to take a long look at making PAIR! into a float-based 
point, to allow better control with graphics. This somewhat non-trivial 
due to the assumptions in code that PAIR! is integer only with truncation 
for math operations.

in R3 I could go far beyond, actually dumping some of liquid's processing 
directly in the native side of an extension.


in fact, I could use AGG or OpenGL directly without even using gobs 
or draw blocks since the interface is built by how you link things 
together and this linking and messaging will automatically fire-off 
AGG commands, without the need to go through an intermediate.

if you download the OpenGL demo, there is a complete working setup. 
 it has a makefile and a visual studio 2008 setup .  it should help 
you out.

I know Maxim likes OpenGL too.

it took me just a few hours to have OpenGL running in an extension.... 
 which includes downloading all the OGL libs, and C compiler and 
stuff.

Now soon, GUI work will continue and there are graphics subsystem, 
OpenGL, etc. Enough work for 4-5 people there alone.

yes, OpenGL

as I explained to sunanda, while doing the OpenGL port I decided 
to build my C code analyzer/compiler/converter to make the process 
as complete and painless as possible...


but I've hit a wall and need a better unit testing engine to complete 
that and the OpenGL convertion.

honestly I don't know, but its a funded project overall, so it is 
my current job.  which means it will happen for sure.


I would love to have some usefull OpenGL stuff working in february.

even for the OpenGL implementation, the next host will make my job 
easier AFAIK.

Maxim, no problem, I have not much time either now so feel free to 
clarify any time later.

I was just wondering what you are looking for to satisfy your needs.

And of course, you cannot request functionality of big complex 3D 
systems which are usually fat high-level layers over  low level graphics 
libraries.

You should think about the DRAW at the level of graphic library api, 
not application layer.

So I more awaited comparison with OpenGL, DIrectX, Cairo, Qt , Java2d 
 and so on. Anyway, I'm curious about your  examples....

Also I don't understand what is so wrong on using dialect as an interface 
when Rebol should be the case where working with blocks, dialects 
etc. should be a plus.

For example If you prefer interface based on function calls over 
dialect the I'd like to know what benefits you see in that approach 
etc.

OpenGL

rather than enhance AGG 2.4 .. why not move to OpenGL ?

I'm not sure openGL can cover what AGG does and vice versa.

an extension linkin agg and  opengl would be awsome and crazy at 
same time
that's sad the developpement stopped

can opengl be  used the same extends as AGG hum ... opengl have a 
heavy mechanics and that's not suited in my opinion for 2D fast over 
face rendering

the thing is draw and so agg can be used on any widget  componing 
VID and that's a hugde constraint

what really sux with opengl are those  half assed IHM interface i 
know glut, x and w32 extension that allows the opengl rendering engine 
to recive user

events and then display  on screen in the particular area set for 
it.


Those interfaces are not 1% as fun as VID... Vid is total flexibility. 
we never did that in vid be you can imagine heavy animation using 
draw dialect on any kind

of preset styled face. I think carl tryed to show that with the animated 
sliding widget when you open a window in his R3 GUI demo.

for me doing 2D using opengl always apeared to me as using a nuclear 
bomb to kill a single poor tiny cute ant ...(ok ant isn't cute...)

things like transparency could be handled a way faster using opengl

comparing AGG antialising and opengl antialiasing is like comparing 
the sun and the moon ...

but in opengl  you don't have  a proper way to handle fonts who wants 
to have flat texels to represent is document or hundreds of  png 
files in memory ... and that where glut and other extensions try 
to give solutions but the réalisaton is in général ugly.

but you have an image surface ... wher you can clip any rvb content 
... even opengl buffer ?

i mean you can trop opengl rendering in a file why not traping it 
to a image buffer and then display it

was i more clear with that example (taht's the way GTK+ and QT link 
with opengl you have a specific squared area to clip your opengl 
rendering in  but  it's not mixed content

right now I'm busy integrating OpenGL within a gob!  :-)

a question... is there a single place where a gob is destroyed (maybe 
a callback or some method) within the host-kit?  just so its more 
invisible, when I need to detach a gob from the OpenGL rendering 
context... at this point I have all I need to build an OpenGL gob.. 
but nothing to get it automatically cleaned up.

GOB is 'destroyed' by GC AFAIK so you shouldn't rely on that event 
imo. I don't know details of your implementation but making separate 
OpenGL context for every GOB doesn't seems to me as a good idea.

the gob will act as a container for an OpenGL context (and viewport).


so a single gob! will store the whole 3d scene, not just a single 
poly/shape.   I guess I'll have a command block similar to gob!/draw 
 to define some aspects of a 3D scene (though not everything... since 
3D is pretty heavy... probably things will be loadable from ram and 
disk)

Yes, this is not so easy to do as you need to always manage the window 
differently for almost every gfx system. I have in works AGG accelerated 
using OpenGL using one trick which makes things much easier and still 
pixel precise. But I need to try convert the pure c++ prototype code 
into the Hostkit first to see how it behaves in 'real world' usage 
cases...

the question I am asking myself is if I can have both an OpenGL and 
Direct gob! in the same window  :-D

OpenGL and DirectX can give you different rendering capabilities, 
so I think there is nothing wrong with having both in the same window 
for comparison side by side.

the reason I am working hard on the R3 OpenGL engine is that I want 
to be able to display hundreds of thousands of things in real-time, 
smoothly.

anyhow... back to OpenGL in R3  ;-)

host kit will fix remaining graphics issues, which Cyphre is already 
preparing. It will also help prepare for a better console for all 
platforms. Robert and Maxim has done various implementations (OpenGL, 
SQLite) and are doing general tests. BrianH, I can't remember what 
he's doing...

I was able to trigger button & keyboard events from  a GLut  (OpenGL) 
window,  running arbitrary code like normal view actions.


Nice thing is that the errors do not stop the interpreter, just that 
call to Reb_Do_String() so its like if your code was wrapped within 
an attempt by default  :-)

Good progress anyway. I noticed Twitter message mentions OpenGL. 
Well, I hope we get VID 3.4 with some nice bunch of styles first 
:-)

CPU are not feated with matrix computations because the industry 
decided that matrix area was such a big thing that they needed a 
spécific library and a specific hadware extensivly optimised to perform 
those computations. and so the GPU accellerated enhanced for opengl 
and DirectX is born.... Now in day the industry use most likely the 
DirectX because  well 90% of the personal computers are windows and 
that 100% of them support DX so 100% of the sold PC games are done 
that way... And that allow to cut cost when another company like 
unreal tech for example make a game engine you buy it and you save 
alot of time and monney the only thing you will have to do then is 
to create the specific IHM for your game and all the visual /audio 
content. then your project  time spent is shorted by 2 or 3 years...

AGG is not the best place to put OpenCL support. OpenCL is not very 
useful for accelerating graphics, and that is what AGG would need. 
A standalone OpenCL dialect would be more useful. Graphics acceleration 
uses other APIs, like OpenGL or Direct2D. AGG isn't 3D, so using 
OpenGL or Direct3D would be equivalent to reimplementing Direct2D 
on platforms that don't support it.

could then moonlight and mono be interfaced with other side libraries 
like opengl  can i make a part of my interface as an opengl display 
etc??

With Silverlight/Moonlight, you don't need a side interface, it has 
a GUI. That GUI will be accellerated by OpenGL or whatever is available. 
With Mono, you can integrate anything.

OpenGL GLUT events are driven by callbacks, which we can now push 
into REBOL "user space".


so for example, you provide an on-key() or on-mouse-down() callback, 
and you receive the events, directly at the function.

speaking for myself...  all of my concerns wrt A108 *are* the changes 
in the core wrt how they affect extensions.


The fact that R3 itself is better is cool, but doesn't really allow 
me to test anything if I can't actually compile the host-kit against 
it.


though I know how preparing working releases takes time, so I'm probably 
a bit more patient than Andreas.  ;-)


I will be starting work on my Custom Gob Renderering A107 R3 host-kit 
sometime this week.  

I still have to *complete* the rendering pipeline architecture from 
end to end (even if its currently very shallow), which is about 80% 
done.

most of what is left is the easy part (the actual OpenGL handling 
itself)

I'm about to prepare a package which has a working version of openGL 
in view...

I think about others DLLs, like OpenGL.

Ok, I get this error:


>> opengl: import %/System/Library/Frameworks/OpenGL.framework/OpenGL

** syntax error: script is missing a REBOL header: %/System/Library/Frameworks/OpenGL.framework/OpenGL

So such DLLs need to be wrapped in some REBOL code, or?

We've been working with Karl to get the Boron OpenGL demo working, 
and it's now set up and smooth