World: r3wp

pekr... wrt wait, cause I didn't have time to add MM timers to the 
host yet.

ech.. hotbook.. good name for mine:)

Oldes, the other thing I am thinking is that it might be the disk 
paging some stuff.

why you should do it? IIRC, we already have more precise timers ...

not timers... counter... not the same thing.   precise counters use 
the Clock frequency to measure time differences.

they don't trigger events.

MM timers use more precise interrupts so allow sub ms event timing.

though they are deprecated starting in vista, in preference to queued 
events, which I think aren't as precise.

seems like the .obj importer/viewer script is gone, but the script 
may have been done by a Jan Skibinski. I clearly remember seeing 
a script that displayed a green model of R2D2 in a regular R2/View 
window.

btw - http://www.rebol.net/r3blogs/0088.html

Max - scrap the MM thing. We don't need another non supported timers. 
Queued timers is the way to go then ...

that is only true on linux.

Windows... the OS doesn't allow sub 15ms timing. using standard window 
events... its hard-coded in the event engine.

it doesn't really matter from the r3 script's point of view.   but 
MM timers are a bit more precise since they even allow for audio 
frequency precise timing.

the issue is that in vista/win 7 there are new multi-media libraries 
which aren't accessible by WinAPI which sucks.

http://www.codeproject.com/KB/system/timers_intro.aspx

Queue timers is the only way to go ...

yep, I read the whole MSDN section on the differences between queue 
and MM timers, they both have advantages.

MM timers where replaced by new stuff in the new interface system 
which is part of silverlight/net  I can't remember the name of it.

Does deprecated means - still awailable, but not suggested to be 
used? I mean - what if Win 8 in 2 years removes them?

the way I see it, win8 will remove a lot more than MM timers.

but really, its not a big deal what is used as long as the r3 API 
doesn't change from one OS to the other.

Cyphre and I prefer to use timer setup funcs rather than merge them 
within the gob infrastructure.

timers are rarely needed for a control specifically.  usually you 
want the timer to handle things like network pings, fps controled 
redraws, etc.

so its probably going to be something like:

timer/cycle 'my-func-timer 0:01:01 my-func
and to stop it just use timer/stop 'my-func-timer

uh - what's that? Too complicated - timer/cycle 'my-func-timer 0:01:01 
my-func

That should be discussed elsewhere, as well as discussed with Carl, 
along the lines of tasking and IPC model, etc. I think that timers 
could be usefull outside the GUI too ...

ah... what complicated... 

timer/mode label delay or time function.

honestly, I know carl doesn't care about such a trivial issue... 
if we build it and it works why would he argue?  he does listen to 
our ideas when we have tests and code to show.

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 ?  ;-)

note that a lot of this is covered in more details in the various 
ReadMe files I took the time to write prior to release.

btw it is working with multiple CGR gobs, the issue is just that 
I'm having a bit of trouble determining exactly what coordinates 
to use  and they are currently always at 0x0 offset.

I'm working on this right now.

FYI, your latest release works for me, Win 7 64 bit, Radeon 5770 
with 10.10 drivers, in the sense of not crashing, but the actual 
3D shape being drawn is not really visible. It is vaguely visible 
as the drawing surface is rendered and you see flickering bits of 
the surface, here and there

did you try with the torus scene?

I would love to get a screengrab... I might have ideas of the cause 
but without a pic its going to be tough to fix it if its indeed a 
bug.

if you press on the window edge (which stops animation) does the 
model appear completely?

the animation doesn't seem to stop when clicking the window edge, 
for me

as for a screen grab, I think I'd probably capture a black window 
- the actual shape is seen very intermittently, just a flicker now 
and then

yeah, tried to capture and all I get is black

very strange, since I'm calling the most basic open gl stuff.

ati always had less than optimal opengl support

but I would have thought that its getting better with all those ati 
cards in macs... anyhow  it could even be an issue specific to win 
7 in 64 bits.

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

go cyphre, go :-) The more general way is always better. OTOH why 
not add field here or there - but - not for the purpose of one user, 
but once again, upon the well defined purpose ...

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.

I'll try whatever you want me to. As a point of note, it kind of 
looks like the animation is showing 1 in 10 to 30 frames or so. Also, 
I'm not sure that the colour rendering is OK - there seem to be too 
few colours used. Can you take a screen cap showing the torus on 
your end?

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

The colours look OK, comparing to your output. Is there anything 
in your offscreen buffering that could be an issue?