> Moray would also benifit from an overhauled patch modelling system,
> personally i find the current system a nightmare to use properly,
> and as spatch seems to be dead in the water these days maybe a 
> merger of sorts would be a good idea.

Indeed!
It would already help a lot if you could change the patches in 3D
windows (there is at least one in the edit tab, normally).

> object masking would be essential as well, meaning the ability from
> within moray to turn of parts of the scene, replacing them with a 
> single large bounding box. currently i have difficulty modelling 
> when this start to get very complex - there are just to many 
> objects for me to be able to see what i am doing, even though where 
> ever possable i model everything seperatly and combine later. this 
> would also help to combat big scene slowdown.

there are methods to do this (global visibility settings- check the
manual to understand the system). The problem is not that this doesn't
exist, but I think it's too difficult to use, so I've never actually
used it.

> another thing that would help with big scene slowdown, would be a
> better method of redrawing the scene, Moray tends to overdraw the 
> same pixel many many times (once for every object that intersects 
> that pixel).

Perhaps it would help if spheres (, cylinders, patches, etc.) wouldn't
just always consist of the same number of lines. What if this depended
from their actual pixel size of the screen? While big spheres could
gain accuracy, smaller ones could be drawn with fewer lines, thus
speeding up things a lot.

=====

Hey! Even more suggestions! There will soon be enough for Moray 4, 5,
...

Florian

Post a reply to this message

Simon de Vet wrote:

> Where will the pair be going in the future?
>
> I imagine that if the project is not abandoned, they will continue to
> grow closer and closer. Eventually (in a far future?) it would be
> possible to use one program with the ease of use and visualization of
> Moray, and all the scripting power of straight pov code.

>
>
> In an ideal world, the end product would be a renderer that is a good
> tool for the most diehard POVer, but also something a complete newbie
> can jump into and feel comfortable.
>
> Ah well... it's a nice dream. Every step Moray takes is one step closer
> to realising the dream.

Well the scripting as a plug in that would allow users of Moray to copy
snippets of Pov code into the "editor window" then let moray make the
object it's way from the code would be a GREAT help IMHO....

Post a reply to this message

Hi Florian Fischer, you recently wrote in moray.win:

> there are methods to do this (global visibility settings- check the
> manual to understand the system). The problem is not that this doesn't
> exist, but I think it's too difficult to use, so I've never actually
> used it.
Yes, this is not a optimal solution and one of the things we have
planned for a later version (not the next one) is a normal layer
system as many other packages have them.

> Rick wrote: 
> > another thing that would help with big scene slowdown, would be a
> > better method of redrawing the scene, Moray tends to overdraw the 
> > same pixel many many times (once for every object that intersects 
> > that pixel).
Yes, only the edges are drawn and if they overlap (which they always
do when there are lots of objects, they are drawn multiple times.
Checking whether the pixel has been drawn wouldn't change anything,
except slow down the redraws.

> Perhaps it would help if spheres (, cylinders, patches, etc.) wouldn't
> just always consist of the same number of lines. What if this depended
> from their actual pixel size of the screen? While big spheres could
> gain accuracy, smaller ones could be drawn with fewer lines, thus
> speeding up things a lot.
That's a good idea, but is unsuitable for the current way that the
edges are handled in Moray. This is because you could have up to four
different settings for size on screen and we'd then need four
*different* edge lists, instead of the single one we have now. This
means four-times the memory footprint.

> Hey! Even more suggestions! There will soon be enough for Moray 4, 5,
Hehe, and you haven't even seen the long list that we'd like to
implement<g>.

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Rick wrote:
> 

> Moray would also benifit from support of other solids based render engines
> (some one mentioned BMRT) but this would ONLY be worth doing if moray could
> be as compatable with that system as it is with POVray, being able to use a
> only a subset of the target render engines capabilities would be almost
> pointless - a bit like the early polyray plugin.

I believe that the way to get compatability with other rendering engines
is through some of the newest additions to the plugin interface.  Most
notably the ability of one plugin to talk to another.

The idea here is that features of one rendering system that aren't
supported by Moray (or by POV-Ray for that matter) could be implemented
as a plugin, which would then directly talk to the plugin that is
supporting the alternate renderer.

> 
> Moray would also benifit from an overhauled patch modelling system,
> personally i find the current system a nightmare to use properly, and as
> spatch seems to be dead in the water these days maybe a merger of sorts
> would be a good idea.

I agree - polygonal modelling capabilities with conversion to
subdivision surfaces.

> object masking would be essential as well, meaning the ability from within
> moray to turn of parts of the scene, replacing them with a single large
> bounding box.

You can do that.  A nice addition to the current capability would be to
have layers.

Xander

Post a reply to this message

> Thanks for the great feedback. I'll make sure we think about all your
> points. One of them is already in the next version (the Material
> Editor and Library cache the textures).

Hurrah! psychic Lutz !

Rick

Post a reply to this message

> > object masking would be essential as well, meaning the ability from
within
> > moray to turn of parts of the scene, replacing them with a single large
> > bounding box.
>
> You can do that.  A nice addition to the current capability would be to
> have layers.

damn, i knew i missed something! - yes and layers :)

Rick

Post a reply to this message

Rick <pov### [at] dialpipexcom> wrote in article <3846a0f6@news.povray.org>...


> A simpler plugin system (as discussed on sdk-list) would be a real
> advantage, something allong the lines of beginner VB would be perfect -
draw
> your UI then write simple and easy to learn code to power it.


	For christ's sake, not VB - that's a horrible
travesty of a programming language. It's not even 
object-oriented! 




> the ability to parse POV script would be a
> real step forward - even a limited subset of the full language would be
> extremly usefull 

	I wrote a grammar for a subset of POV using
a Java parser called JavaCC. I use it to turn POV models
(output from Moray) into nested objects that I can combine 
and manipulate and then turn back into POV format. It
works fine but I'd like a formal description of POV language - 
does such exist?

				David

Post a reply to this message

> It works fine but I'd like a formal description of POV language -
> does such exist?

No.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

> > A simpler plugin system (as discussed on sdk-list) would be a real
> > advantage, something allong the lines of beginner VB would be perfect -
> draw
> > your UI then write simple and easy to learn code to power it.
>
>
> For christ's sake, not VB - that's a horrible
> travesty of a programming language. It's not even
> object-oriented!

Err, i think you will find it is, and remeber i was refering for a plugin
language for the masses, if VB was a little quicker, and didnt require
runtimes, nobody would bother with VC. (except maybe from the hard asses who
browse the web with a text based browser)

Rick

Post a reply to this message

Rick <pov### [at] dialpipexcom> wrote in article <387325fa@news.povray.org>...


> > VB is not even object-oriented!

> Err, i think you will find it is

	No, it's not, because it has 
no Inheritance. 



	If you want reasons why I called it 'horrible' 
I could write a much longer reply, but this is not the
correct newsgroup.


>, and remeber i was refering for a plugin
> language for the masses

	Well, VB won't do anything for 
the Linux masses.


				David

Post a reply to this message