Thanks all , i started to feel bad, as artist i'm very "sensitive", you
know. 
Greg : "What are your motivations, goals, etc.? Without spelling some of
these things out, it's difficult to know when and how others might
help you."
I work in a spanish version of Visarc and i thought, as many people, that a
realtime
architecture visualizer would be cool for my work. Rholo is a very powerful
program, but
has the problem that in architecture straight lines(edges) are very
important , and rholo gets (still) a bit
slowly the refined image.
Now i am merging rview and glrad, so you can swicth from one to other with
an icon click. In future i
would like to reuse glrad opengl depth values to optimize the rview ray
intersects, and try to find other
ways to optimizing rview speed without compromising accurate, althought i'm
sure it will be a hard work
because greg has done a very good work.
merging rview and glrad over a windows system i've found some problems, as
glrad uses for mesh conversion
the same pointer to functions as rview for ray intersects (face, sphere...),
it is resolved using a exernal rtrace
process for rview that in addition alows not to idle the windows enviroment.
Ian : "Sure. A nicer GUI would be good. And the non-X11 (Windows and OS/X)
users
would probably like a native replacement for rview/rvu."
I would like to make a very easy program, so all windows users can use it
but also hold every possible radiance
options and ways of work so advanced users can use it too.
"If I were trying to maintain a native Radiance description in an
editor, I'd probably require the user or CAD system isolate objects
in separate scene files. My editor would then place these with the
appropriate xform's or instances (a la replmarks) in the main scene,
possibly building a hierarchy. I wouldn't attempt to parse all the
various scene-generating commands in Radiance, particularly because
users are allowed and encouraged to write their own."
Yes i got the same conclusion,and i think it will be the best way. but i'm
now wondering what can i do
with material edition. a parser the erases all material definitions and
creates a memory structure and
an additional material file?
"Yes, I think that the persistent mode of rtrace and rpict have been a
persistent problem under Windows, so to speak. Why don't you simply
track which rays belong with which views, and discard returned rays
from the previous view(s)? That way, you don't have to restart
rtrace, which is bound to be a lot more expensive than discarding a
few rays. So long as your input queue to rtrace is held to a
reasonable length, i.e., the average number of rays it computes in a
second, the delay should be tolerable. This is the approach I take
in rholo, for instance."
yes but it would be very nice that rview can show something( 1,4,8.. nodes)
at interactive speed(while orbiting, dolling ...), isnt it?