AltME groups: search

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.

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.

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?

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

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.

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.

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.

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

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.

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

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.

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

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

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.

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.

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

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.

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

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

The zip is a different size, so I don't think so. Complex and Torus 
are dated yesterday, the others for the 25th and 26th.

Max, I'm expierencing the same flickering as Adrian does, I'm running 
on a 3/4 year old Sony VAIO with Win7. I can't supply any further 
detail, I'm don't have access to the machine right now. I see a flickering 
torus , a flickering  simple tree and no complex tree at all. When 
I'm back at the machine, I'll try with the AA settings which Adrian 
seems to have identfied as the source of the confusion in just this 
moment.

its probably just a simple glCall to do when we settup the viewport.

(simple when we don't want AA... requiring AA probably needs a bit 
more work, since we usually have to chose between what is available)

Thanks. I'm just executing user scripts through a shell script:

There should be a more efficient way, for example if you have a REBOL 
binding to the ulimit function, but the detour through the shell 
script is a quick solution

If you haven't finished it I presume it is not a trivial task

I haven't finished it mainly because I'm not a LDAP user, so I'm 
not familiar with most of the LDAP concepts. The protocol itself 
is quite complex due to ASN.1 encoding.

I wish Frank Sievertsen had put all his code into a repository instead 
of a cd which he then lost!

He had other stuff too .. a shared whiteboard written in Rebol .. 
that was lost

Probably .. i don't need it but it was just an example of software 
that gets lost when not in a public repository

:-) I'm now on a graphical version of Syllable Server

Apparently, there's a dispatch center down right now due to a REBOL 
scripting bug. But, I don't know who to forward the feedback to. 
:(

yes... sick.  but back on track and with a successfull showing of 
my 3D R3 to the potential customer.  so the CGR system will continue 
to be evolved after the holidays.

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.

I'll probably be using my holiday free time to finally release R2 
glass and make a preliminary release of Remark which is tightly coupled 
to cheyenne.

to get glass for R3 is a big endeavour, but after the holidays, possibly 
starting in february, I will be working on this.  


right now I've got a very stable glass for R2 which just needs to 
get its last touches applied to current skin and refurbishments for 
the tutorial I had already started building which is now a bit out 
of date with current state of glass.

(now if I had a mini gui, I could make Rebamp:) I should invest some 
time to the view part as well.

nice work, Oldes.
I agree, a mini gui would allow atractive demos.

There are explanations that some of them are a few days later because 
that used to be the first day that the light could reliably be measured 
to have turned

Anton - can't find the comlib group here.


Can you pass a decimal to Excel?  Or do you format it as string and 
pass it as %s ?

I posted a note on a 2.7.8 problem under !Rebol2 Releases group ( 
for the VIEW release numbered 3.1 at some 800+ Kb )

Thanks a lot, Robert!

Thanks.. so here is a merge with Carl's version https://github.com/Oldes/R3A110

Adrian:  GLASS is currently R2 only, but will be ported in a little 
while.


GLASS R3 will make extensive use of extensions inorder to make it 
as fast as possible, at all levels of the framework.  From Liquid 
right up to the styles themselves.

It will seamleslly integrate to my Custom Gob Renderer so the same 
GLASS style will be able to render in any renderer for which a compatible 
style was built.   


this means the same layout and interface for a button will be useable 
in a normal AGG render up to a 3D game representation of that button, 
with no user code change.  just a swap in the skin being used.

btw..... Thanks everyone for all the cheers, it feels good for some 
of my work to finally have a bit of instant gratification  ;-)


I also want to say thanks to everyone who's taking the time to test 
GLASS.

I am now planning a weekly release cycle.  It will contain all the 
"in-progress" stuff, so will allow people to help in adding new stuff 
if they want.  


If anyone wishes to contribute new styles, new modules, new documentation 
and/or tutorials and  apps, I'll be very happy to include your stuff 
within the distro and properly attribute it.  the only constraint 
is that it has to be BSD and will obviously go through my prying 
eyes, in order to keep consistency with the whole package.

sorry.. it has to be MIT or BSD (I have a preference for MIT, but 
BSD is ok too).

yes, I might github it, but I'm still a bit noob with git, so won't 
do this right now.

I do want to continue with that, but I need to focus first for a 
while on SylCon next week and ReBorCon in a month

That's curious. If I try to unpack    2.4 MB glass-r003.zip, I get 
a folder with just 1.3 MB and only two files in glass/libs. I tried 
with 7zip and the WinExplorer.

It's the only solution he found to bloat a Rebol program ;-)

Seriously : I get an error while unpacking from XP standard zip app.

The problem is on a file named "debug" in the libs folder. So unpacked 
folder is only 2 files length but there is 39 files in the archive.

RMA, panel doc :

The light gray text on white background that you use for code block 
is nearly unreadable. Please darken the text a bit !

ah :-) I thought my carefully planned document scheme was a problem.

so add a class to the HTML used by MD, then go CSS.

I somehow agree with Ashley, though I can understand that you have 
some structure set. The top level menu simply does not show - Docs 
directly. So intuitively I went to Code, and then - huh, what's Level-1? 
If I would not read more about your infrastructure, I would feel 
a bit lost probably :-)

But it's not a big deal to change the structure... if it adds value 
and doesn't bloat the menus.

having access to a pdf copy of the content could be nice also

Thanks to both Kaj and Andreas for taking up the 0mq task. Since 
Andreas made it so easy to try, with prebuilt binaries, I already 
played a bit, and it works fine here. Very exciting stuff guys.

A 3rd generation Altme client?

I always thought that Cheyenne would be a candidate to leverage ZMQ

Is there a demo with the rma build ?

Yes, it works with the RMA build, but my tests are to check the level 
of compatibility with the standard r3 build, and, to that respect, 
I need to replace the load-gui by a do %r3-gui.r3. (At least, I suppose, 
I have not checked)

About disreb: Sorry to be unclear originally. At the moment, it's 
R2 only (I'm currently sticking with the latest version of R2 because 
I understand that it has a more stable GUI), however I am very willing 
to incorporate changes for R3. I'm not yet sure what the best fashion 
of collaboration with the Google code site is, but hopefully I'll 
have some time to investigate tomorrow. Sorry for the late reply, 
but I have imperfect access to AltMe (it's firewalled at work and 
I forgot my password (ha!) so I don't have it working on the computer 
I'm programming disreb with). @Oldes, I hope you find it useful should 
you chance to use it! Thanks!

Robert, it can do both sync and async. But no callbacks, async is 
done using a WAIT-style (or select/epoll-style, if you prefer) approach, 
using zmq-poll.

Robert: you have two primitives send & recv. Both _block_ per default: 
send until there it manages to enqueue the message in an internal 
buffer, recv until it fully read a message. You call both functions 
with a NOBLOCK flag, in which case they won't block but return immediately, 
with an EAGAIN status code in case they did not manage to write/read 
anything. Finally, you also have a poll primitive, to which you pass 
a list of sockets you are interested in and an (optional) timeout. 
Poll returns you a list of sockets which are "active", i.e. which 
can be safely read from (or written to) without blocking.

ddharing: The 200kmsgs/sec results are from a run on Linux.

MaxV: remind me a script I made 8 years ago :
d http://membres.lycos.fr/didec/rebsite/whoswho/whoswho.r

Odd, it doesn't warn me if the skew is within a few minutes or so. 
Anyway, it seem to be just a warning, and I wouldn't worry about 
13 seconds

13 seconds today, half a minute next month, ...

Does Fossil issue a warning when you update?

I'm on the previous version of a month before, so maybe that makes 
a difference

You're reporting a difference, aren't you?

The difference is most likely that my systems have a synced time, 
whereas your workstation has not.

It does not, but it'll give everyone with a synced time a warning 
on each and every clone/pull.

If a newer Fossil version would fix it, I would have been willing 
to update, though

But obviously, it's not something that keeps Fossil from working, 
it's just a friendly reminder that it tailors to the habits of the 
local user

And it will try to prevent you from creating a check-ins that are 
"earlier" than their parents.

Or for a single contributor trying to create two check-ins in quick 
succession.

Steeve, that's sweet. "Case" doesn't show up in the dictionary and 
I had no clue we had such a thing. Very cool.

I use it a lot. CASE/ALL is also useful.

The help says this:
    -- args          Provide args without a script

There's a space between the -- and the word args, so I tried this 
and it worked:

   rebol --do '? system/script/args q' -- 'arguments here'

The help should probably say something like:
   -- <args>
to make it more obvious