From: CL <clc...@gm...> - 2009-01-15 10:01:03
|
About the opacity problem (crash when changing from opacity 1.0 to lower), it looks like it is a bug in frame.cpp void frame::gl_render( const view& v) .... for (child_iterator i = children.begin(); i != child_iterator(children.end()); ++i) { if (i->translucent()) { // See display_kernel::draw(). trans_children.push_back( *i.base()); i = children.erase(i.base()); continue; } i->outer_render(local); } The code is trying to move a renderable from a list to another list when the opacity of the renderable is changing from 1.0 to something else. But children.erase() function returns the pointer after deletion, not the pointer before deletion. Following similar logic in display_kernel::draw, replace the code with : child_iterator i(children.begin()); child_iterator i_end(children.end()); while (i != i_end) { if (i->translucent()) { // See display_kernel::draw(). trans_children.push_back( *i.base()); i = children.erase(i.base()); continue; } i->outer_render(local); i++; It seems working on my simple test cases. >Don't I wish it were that simple. No, objects are created with >opacity=1.0 by default. That's why a scene contains opaque objects if >you don't explicitly set the opacity to something different. >b = box() >print b.opacity # shows 1.0 >Bruce Sherwood |
From: Bruce S. <Bru...@nc...> - 2009-01-15 14:53:10
|
Many thanks for looking into this! I'll try it. More generally, it would be a much healthier situation for VPython if more users would/could get involved at this level. Such help is greatly appreciated by everyone in the community. Bruce Sherwood CL wrote: > About the opacity problem (crash when changing from opacity 1.0 to > lower), it looks like it is a bug in frame.cpp > > void frame::gl_render( const view& v) > > .... > > for (child_iterator i = children.begin(); i != > child_iterator(children.end()); ++i) { > if (i->translucent()) { > // See display_kernel::draw(). > trans_children.push_back( *i.base()); > i = children.erase(i.base()); > continue; > } > > i->outer_render(local); > } > > The code is trying to move a renderable from a list to another list > when the opacity of the renderable is changing from 1.0 to something > else. But children.erase() function returns the pointer after > deletion, not the pointer before deletion. > > Following similar logic in display_kernel::draw, replace the code with : > > child_iterator i(children.begin()); > child_iterator i_end(children.end()); > while (i != i_end) { > if (i->translucent()) { > // See display_kernel::draw(). > trans_children.push_back( *i.base()); > i = children.erase(i.base()); > continue; > } > i->outer_render(local); > i++; > > It seems working on my simple test cases. > > >> Don't I wish it were that simple. No, objects are created with >> opacity=1.0 by default. That's why a scene contains opaque objects if >> you don't explicitly set the opacity to something different. > >> b = box() >> print b.opacity # shows 1.0 > >> Bruce Sherwood > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Visualpython-users mailing list > Vis...@li... > https://lists.sourceforge.net/lists/listinfo/visualpython-users |
From: CL <clc...@gm...> - 2009-01-16 00:36:59
|
Hi Bruce Not at all. Unfortunately I am not very experienced in low level graphics/opengl development, I can only help at surface level / minor logic bug level. CL On 1/15/09, Bruce Sherwood <Bru...@nc...> wrote: > Many thanks for looking into this! I'll try it. > > More generally, it would be a much healthier situation for VPython if more > users would/could get involved at this level. Such help is greatly > appreciated by everyone in the community. > > Bruce Sherwood > > CL wrote: > > > > About the opacity problem (crash when changing from opacity 1.0 to > > lower), it looks like it is a bug in frame.cpp > > > > void frame::gl_render( const view& v) > > > > .... > > > > for (child_iterator i = children.begin(); i != > > child_iterator(children.end()); ++i) { > > if (i->translucent()) { > > // See display_kernel::draw(). > > trans_children.push_back( *i.base()); > > i = children.erase(i.base()); > > continue; > > } > > > > i->outer_render(local); > > } > > > > The code is trying to move a renderable from a list to another list > > when the opacity of the renderable is changing from 1.0 to something > > else. But children.erase() function returns the pointer after > > deletion, not the pointer before deletion. > > > > Following similar logic in display_kernel::draw, replace the code with : > > > > child_iterator i(children.begin()); > > child_iterator i_end(children.end()); > > while (i != i_end) { > > if (i->translucent()) { > > // See display_kernel::draw(). > > trans_children.push_back( *i.base()); > > i = children.erase(i.base()); > > continue; > > } > > i->outer_render(local); > > i++; > > > > It seems working on my simple test cases. > > > > > > > > > Don't I wish it were that simple. No, objects are created with > > > opacity=1.0 by default. That's why a scene contains opaque objects if > > > you don't explicitly set the opacity to something different. > > > > > > > > > > b = box() > > > print b.opacity # shows 1.0 > > > > > > > > > > Bruce Sherwood > > > > > > > > ------------------------------------------------------------------------------ > > This SF.net email is sponsored by: > > SourcForge Community > > SourceForge wants to tell your story. > > http://p.sf.net/sfu/sf-spreadtheword > > _______________________________________________ > > Visualpython-users mailing list > > Vis...@li... > > > https://lists.sourceforge.net/lists/listinfo/visualpython-users > > > |