## Re: [Playerstage-users] blocks

 Re: [Playerstage-users] blocks From: Tyler J. Gunn - 2009-11-27 14:34:01 ```> I'm trying to convert some of my old Stage 2.1.1 models to use Stage > 3.2.2 but I'm having trouble making the blocks render properly. > In my robot's "position" model I have two blocks, declared with the > following code: Hi Jenny, I've experiened this same problem before when defining models. The trick is you need to define the points that make up the block-polygon in a counter-clockwise fashion. In this block, if you plot the points out, you'll notice that from 0 to 5 they're plotted in a clockwise manner. Thus they will not appear solid (seems to be how the block rendering works): > block( > points 6 > point[0] [-0.5 -0.5] > point[1] [-0.5 0.5] > point[2] [0.25 0.5] > point[3] [0.5 0.25] > point[4] [0.5 -0.25] > point[5] [0.25 -0.5] > > # z [height_from height_to] > z [0 0.22] > ) In this block the points are defined in a counter-clockwise direction, and they will appear as a solid block: > block( > points 8 > point[0] [-0.2 0.12] > point[1] [-0.2 -0.12] > point[2] [-0.12 -0.2555] > point[3] [0.12 -0.2555] > point[4] [0.2 -0.12] > point[5] [0.2 0.12] > point[6] [0.12 0.2555] > point[7] [-0.12 0.2555] > z [0 0.22] > ) > I'm using Player version 3.0.0 if that's important. > Does anyone know why the first block does not get filled in like a solid > object? It took me a while to figure it out too. :) My undergrad graphics classes are pretty rusty in my mind, but I suspect this has to do with how the blocks are being translated into 3D objects. Using a counter-clockwise definition defines the surface normal of the polygon to be coming towards you, rather than away from you. Hope this helps, Tyler Gunn University of Manitoba ```

 [Playerstage-users] blocks From: Jenny Owen - 2009-11-27 11:58:57 ```Hi, I'm trying to convert some of my old Stage 2.1.1 models to use Stage 3.2.2 but I'm having trouble making the blocks render properly. In my robot's "position" model I have two blocks, declared with the following code: block( points 6 point[0] [-0.5 -0.5] point[1] [-0.5 0.5] point[2] [0.25 0.5] point[3] [0.5 0.25] point[4] [0.5 -0.25] point[5] [0.25 -0.5] # z [height_from height_to] z [0 0.22] ) block( points 8 point[0] [-0.2 0.12] point[1] [-0.2 -0.12] point[2] [-0.12 -0.2555] point[3] [0.12 -0.2555] point[4] [0.2 -0.12] point[5] [0.2 0.12] point[6] [0.12 0.2555] point[7] [-0.12 0.2555] z [0 0.22] ) My problem is that the 6 pointed block just becomes walls (bad) but the 8 pointed block is a proper block which is filled in. I uploaded a picture here: http://www-users.cs.york.ac.uk/jowen/player/fillinblock.png and in the fancy new perspective view: http://www-users.cs.york.ac.uk/jowen/player/fillinblockperspective.png I don't see what the difference in the syntax is that would cause this to happen! Both blocks are on the same robot so I don't think it's a problem in the rest of my code, just the bits I've pasted here. I've uploaded the code that generated this simulation here if anyone wants to read it: http://www-users.cs.york.ac.uk/jowen/player/bigbob.tar I'm using Player version 3.0.0 if that's important. Does anyone know why the first block does not get filled in like a solid object? Thanks, Jenny ```
 Re: [Playerstage-users] blocks From: Tyler J. Gunn - 2009-11-27 14:34:01 ```> I'm trying to convert some of my old Stage 2.1.1 models to use Stage > 3.2.2 but I'm having trouble making the blocks render properly. > In my robot's "position" model I have two blocks, declared with the > following code: Hi Jenny, I've experiened this same problem before when defining models. The trick is you need to define the points that make up the block-polygon in a counter-clockwise fashion. In this block, if you plot the points out, you'll notice that from 0 to 5 they're plotted in a clockwise manner. Thus they will not appear solid (seems to be how the block rendering works): > block( > points 6 > point[0] [-0.5 -0.5] > point[1] [-0.5 0.5] > point[2] [0.25 0.5] > point[3] [0.5 0.25] > point[4] [0.5 -0.25] > point[5] [0.25 -0.5] > > # z [height_from height_to] > z [0 0.22] > ) In this block the points are defined in a counter-clockwise direction, and they will appear as a solid block: > block( > points 8 > point[0] [-0.2 0.12] > point[1] [-0.2 -0.12] > point[2] [-0.12 -0.2555] > point[3] [0.12 -0.2555] > point[4] [0.2 -0.12] > point[5] [0.2 0.12] > point[6] [0.12 0.2555] > point[7] [-0.12 0.2555] > z [0 0.22] > ) > I'm using Player version 3.0.0 if that's important. > Does anyone know why the first block does not get filled in like a solid > object? It took me a while to figure it out too. :) My undergrad graphics classes are pretty rusty in my mind, but I suspect this has to do with how the blocks are being translated into 3D objects. Using a counter-clockwise definition defines the surface normal of the polygon to be coming towards you, rather than away from you. Hope this helps, Tyler Gunn University of Manitoba ```
 Re: [Playerstage-users] blocks From: Richard Vaughan - 2009-11-27 17:09:31 ```Hi Jenny, Tyler is correct. Stage's simulation engine doesn't care which way the ploygons are "wound" (as the lingo goes), but OpenGL is fussy so they look wrong in the GUI. This is a serious usability bug, as you've discovered. Stage should internally sort the points to satisfy OpenGL. Patches to do this are most welcome! Thanks for the reply, Tyler. Richard/ On Fri, Nov 27, 2009 at 6:33 AM, Tyler J. Gunn wrote: >> I'm trying to convert some of my old Stage 2.1.1 models to use Stage >> 3.2.2 but I'm having trouble making the blocks render properly. >> In my robot's "position" model I have two blocks, declared with the >> following code: > > Hi Jenny, > > I've experiened this same problem before when defining models. The trick > is you need to define the points that make up the block-polygon in a > counter-clockwise fashion. > > > In this block, if you plot the points out, you'll notice that from 0 to > 5 they're plotted in a clockwise manner.  Thus they will not appear solid > (seems to be how the block rendering works): > >> block( >>       points 6 >>       point[0] [-0.5 -0.5] >>       point[1] [-0.5 0.5] >>       point[2] [0.25 0.5] >>       point[3] [0.5 0.25] >>       point[4] [0.5 -0.25] >>       point[5] [0.25 -0.5] >> >>       # z [height_from height_to] >>       z [0 0.22] >> ) > > In this block the points are defined in a counter-clockwise direction, and > they will appear as a solid block: > >> block( >>       points 8 >>       point[0] [-0.2 0.12] >>       point[1] [-0.2 -0.12] >>       point[2] [-0.12 -0.2555] >>       point[3] [0.12 -0.2555] >>       point[4] [0.2 -0.12] >>       point[5] [0.2 0.12] >>       point[6] [0.12 0.2555] >>       point[7] [-0.12 0.2555] >>       z [0 0.22] >> ) > >> I'm using Player version 3.0.0 if that's important. >> Does anyone know why the first block does not get filled in like a solid >> object? > > It took me a while to figure it out too.  :) > > My undergrad graphics classes are pretty rusty in my mind, but I suspect > this has to do with how the blocks are being translated into 3D objects. > Using a counter-clockwise definition defines the surface normal of the > polygon to be coming towards you, rather than away from you. > > Hope this helps, > Tyler Gunn > University of Manitoba > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now.  http://p.sf.net/sfu/bobj-july > _______________________________________________ > Playerstage-users mailing list > Playerstage-users@... > https://lists.sourceforge.net/lists/listinfo/playerstage-users > -- Richard Vaughan Autonomy Lab / Computing Science / Simon Fraser University ```