|
From: doug s. <hig...@ho...> - 2013-05-27 14:04:48
|
> I noticed you had to patch trunk so you could build FreeWRL. > I also noticed that some of the fixes you applied where very similar to > the ones I had submitted as patches a while ago... Anyway... Thanks for > that. > > Still, if we enable eai for a linux build it still fails, I think it > requires this patch. > > - #ifdef WIN32 > int iret2; > + #ifdef WIN32 Paulo, OK made that change and checked in. -Doug |
|
From: Paulo E. C. <pau...@gm...> - 2013-05-27 13:48:53
|
On 25/05/13 22:11, doug sanden wrote: > . > I changed to integer mouse coordinates, intercepted earlier so they apply to statusbarHud as well as navigation, clicking and picking. > . > To do this I changed the linux mouse/keyboard handling code and did not verify it on a linux system ** please verify** freewrl -R ../freewrl/tests/1.wrl I do see a file being saved here @ recording/1_wrl.fwplay but I don't think the mouse movements and clicks are being recorded. The keyboard keystrokes seem to be collected but in a weird way I'm not sure I understand. Also, I see some funny characters ... 22 1369662229.734600 "�,2,/,2," "" 23 1369662230.235250 "/,3,�,3," "" 24 1369662230.735990 "" "" 25 1369662231.236659 "" "" 26 1369662231.737341 "d,2,d,3," "" |
|
From: doug s. <hig...@ho...> - 2013-05-27 14:07:19
|
->>> It reports my opengl is 1.5.8 (not enough for GLES2 I gather, which IIRC is about 2.1 or 2.2) >>>>When I run: >>>>freewrl -R >>>>I get: >>>>freewrl: symbol lookup error: freewrl: undefined symbol: fwl_set_modeRecord >>>>That function is one I added recently, and it's working on win32. >>>>Mainloop.c L.3649 >>>>libFreeWRL.h L.244 >>>>options.c L.414 >>>>Any hypotheses? >>>>-Doug >> Probably the new header or source file(s) needs to be added to the >> Makefile.sources in /src/lib >> > I can run it fine from the recent trunk... Interesting, so H: I'm somehow using an older libfreewrl.so? I'll look into that. |
|
From: doug s. <hig...@ho...> - 2013-05-27 14:16:46
|
>> . >> I changed to integer mouse coordinates, intercepted earlier so they apply to statusbarHud as well as navigation, clicking and picking. >> . >> To do this I changed the linux mouse/keyboard handling code and did not verify it on a linux system ** please verify** > freewrl -R ../freewrl/tests/1.wrl > > I do see a file being saved here @ recording/1_wrl.fwplay but I don't > think the mouse movements and clicks are being recorded. > The keyboard keystrokes seem to be collected but in a weird way I'm not > sure I understand. > > Also, I see some funny characters ... > > 22 1369662229.734600 "�,2,/,2," "" > 23 1369662230.235250 "/,3,�,3," "" > 24 1369662230.735990 "" "" > 25 1369662231.236659 "" "" > 26 1369662231.737341 "d,2,d,3," "" > Paulo, very interesting on the keystrokes - I don't know what's going on. With the mouse, I forgot to set if(1) and if(0) in handle_Xevents in MainLoop.c around line 1424 and 1456 - OK I did it now and checked it in. If you update, re-build and re-run you should see the mouse coords. -Doug |
|
From: Paulo E. C. <pau...@gm...> - 2013-05-27 14:39:35
|
On 27/05/13 15:07, doug sanden wrote: > Interesting, so H: I'm somehow using an older libfreewrl.so? > I'll look into that. Try something like ldd the_freewrl_bin_you_are_using | grep -i freewrl to see to which libs it is linking to. |
|
From: doug s. <hig...@ho...> - 2013-05-27 14:56:55
|
>> Interesting, so H: I'm somehow using an older libfreewrl.so? >> I'll look into that. > Try something like > > ldd the_freewrl_bin_you_are_using | grep -i freewrl > > to see to which libs it is linking to. Paulo, Thanks for the tip which helped. -Doug It was linking to an old 'hide' lib. I deleted the old libs and links, then sudo make install again and it got the right lib. The program says "please upgrade to opengl version 2+, press enter to exit" I suspect I can't upgrade -is it limited by the nvidia driver, which is limited by the video board?- if so then I can't run freewrl on my linux box. |
|
From: Ian S. A. <ia...@ae...> - 2013-05-27 15:01:08
|
On 27/05/13 10:56 AM, doug sanden wrote: >>> Interesting, so H: I'm somehow using an older libfreewrl.so? >>> I'll look into that. >> Try something like >> >> ldd the_freewrl_bin_you_are_using | grep -i freewrl >> >> to see to which libs it is linking to. > Paulo, > Thanks for the tip which helped. > -Doug > It was linking to an old 'hide' lib. I deleted the old libs and links, then sudo make install again and it got the right lib. > The program says "please upgrade to opengl version 2+, press enter to exit" > I suspect I can't upgrade -is it limited by the nvidia driver, which is limited by the video board?- if so then I can't run freewrl on my linux box. Option #1 - you can use nouveau -- things might not be that fast but it'll at least render. Option #2 - the latest nvidia-drivers you can use, depending on your hardware, would be as follows: 173.14.37 (for -really- old stuff) 304.88 (for -relatively- old stuff) FYI, the onboard nvidia on my server, bought in 2005, accepts 304.88 and also runs freewrl without any issues. > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may > _______________________________________________ > FreeWRL-develop mailing list > Fre...@li... > https://lists.sourceforge.net/lists/listinfo/freewrl-develop > |
|
From: Ian S. A. <ia...@ae...> - 2013-05-27 15:05:38
|
On 27/05/13 11:01 AM, Ian Stakenvicius, Aerobiology wrote: > On 27/05/13 10:56 AM, doug sanden wrote: >>>> Interesting, so H: I'm somehow using an older libfreewrl.so? >>>> I'll look into that. >>> Try something like >>> >>> ldd the_freewrl_bin_you_are_using | grep -i freewrl >>> >>> to see to which libs it is linking to. >> Paulo, >> Thanks for the tip which helped. >> -Doug >> It was linking to an old 'hide' lib. I deleted the old libs and links, then sudo make install again and it got the right lib. >> The program says "please upgrade to opengl version 2+, press enter to exit" >> I suspect I can't upgrade -is it limited by the nvidia driver, which is limited by the video board?- if so then I can't run freewrl on my linux box. > > > Option #1 - you can use nouveau -- things might not be that fast but > it'll at least render. > > Option #2 - the latest nvidia-drivers you can use, depending on your > hardware, would be as follows: > > 173.14.37 (for -really- old stuff) > 304.88 (for -relatively- old stuff) > > FYI, the onboard nvidia on my server, bought in 2005, accepts 304.88 and > also runs freewrl without any issues. Actually check that -- it DID run freewrl, last time I tried. I should try again. |
|
From: doug s. <hig...@ho...> - 2013-05-27 21:06:24
|
>>> It was linking to an old 'hide' lib. I deleted the old libs and links, then sudo make install again and it got the right lib. >>> The program says "please upgrade to opengl version 2+, press enter to exit" >>> I suspect I can't upgrade -is it limited by the nvidia driver, which is limited by the video board?- if so then I can't run freewrl on my linux box. >> >> >> Option #1 - you can use nouveau -- things might not be that fast but >> it'll at least render. >> >> Option #2 - the latest nvidia-drivers you can use, depending on your >> hardware, would be as follows: >> >> 173.14.37 (for -really- old stuff) >> 304.88 (for -relatively- old stuff) >> >> FYI, the onboard nvidia on my server, bought in 2005, accepts 304.88 and >> also runs freewrl without any issues. > . I had a GeForce2 MX200. Today I bought a GeForce 6200 (PCI) for $50 which says it supports OpenGL 2.1. Then when I did the Additional Drivers search: https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia it came up with a lot more driver options to choose from, including 304, and recommended 'current'. I selected Current, hit the Activate button, rebooted and now freewrl runs and I can see GLES2 stuff like the menu bar. -Doug |
|
From: Ian S. A. <ia...@ae...> - 2013-05-27 17:08:44
|
On 27/05/13 11:05 AM, Ian Stakenvicius, Aerobiology wrote: > On 27/05/13 11:01 AM, Ian Stakenvicius, Aerobiology wrote: >> On 27/05/13 10:56 AM, doug sanden wrote: >>>>> Interesting, so H: I'm somehow using an older libfreewrl.so? >>>>> I'll look into that. >>>> Try something like >>>> >>>> ldd the_freewrl_bin_you_are_using | grep -i freewrl >>>> >>>> to see to which libs it is linking to. >>> Paulo, >>> Thanks for the tip which helped. >>> -Doug >>> It was linking to an old 'hide' lib. I deleted the old libs and links, then sudo make install again and it got the right lib. >>> The program says "please upgrade to opengl version 2+, press enter to exit" >>> I suspect I can't upgrade -is it limited by the nvidia driver, which is limited by the video board?- if so then I can't run freewrl on my linux box. >> >> >> Option #1 - you can use nouveau -- things might not be that fast but >> it'll at least render. >> >> Option #2 - the latest nvidia-drivers you can use, depending on your >> hardware, would be as follows: >> >> 173.14.37 (for -really- old stuff) >> 304.88 (for -relatively- old stuff) >> >> FYI, the onboard nvidia on my server, bought in 2005, accepts 304.88 and >> also runs freewrl without any issues. > > Actually check that -- it DID run freewrl, last time I tried. I should > try again. > So I just grabbed and test built current CVS HEAD on my linux boxen; I'm seeing a -ton- of implicit declarations right now. I expect these are going to cause issues, so I'm going to go through and fix the headers and/or source files this afternoon. Doing this should improve things on all platforms, I expect. |
|
From: Ian S. A. <ia...@ae...> - 2013-05-27 17:13:45
|
On 27/05/13 01:08 PM, Ian Stakenvicius, Aerobiology wrote: > > So I just grabbed and test built current CVS HEAD on my linux boxen; I'm > seeing a -ton- of implicit declarations right now. I expect these are > going to cause issues, so I'm going to go through and fix the headers > and/or source files this afternoon. Doing this should improve things on > all platforms, I expect. > Hey all -- why the removal of '#include "system.h"' from EAI_C_ReWire.c and EAI_C_Node.c ? it's still included in the other files.. was this causing issues for some reason on windows? |
|
From: Ian S. A. <ia...@ae...> - 2013-05-27 19:21:05
|
On 27/05/13 01:13 PM, Ian Stakenvicius, Aerobiology wrote: > On 27/05/13 01:08 PM, Ian Stakenvicius, Aerobiology wrote: >> >> So I just grabbed and test built current CVS HEAD on my linux boxen; I'm >> seeing a -ton- of implicit declarations right now. I expect these are >> going to cause issues, so I'm going to go through and fix the headers >> and/or source files this afternoon. Doing this should improve things on >> all platforms, I expect. >> > > Hey all -- why the removal of '#include "system.h"' from EAI_C_ReWire.c > and EAI_C_Node.c ? it's still included in the other files.. was this > causing issues for some reason on windows? > Answered my own question -- seems it was causing some redefinition of things. I put it back, conditional on #define WIN32, and fixed the collisions. I also de-windows'ized some other function calls in src/libeai/ , everything should be fine but please test to be sure. |
|
From: doug s. <hig...@ho...> - 2013-05-27 22:11:49
|
>>> >>> So I just grabbed and test built current CVS HEAD on my linux boxen; I'm >>> seeing a -ton- of implicit declarations right now. I expect these are >>> going to cause issues, so I'm going to go through and fix the headers >>> and/or source files this afternoon. Doing this should improve things on >>> all platforms, I expect. >>> >> >> Hey all -- why the removal of '#include "system.h"' from EAI_C_ReWire.c >> and EAI_C_Node.c ? it's still included in the other files.. was this >> causing issues for some reason on windows? >> > > Answered my own question -- seems it was causing some redefinition of > things. > > I put it back, conditional on #define WIN32, and fixed the collisions. > I also de-windows'ized some other function calls in src/libeai/ , > everything should be fine but please test to be sure. > After a touch-up it builds on win32. I don't have an automated test suite set up, didn't try it. -Doug |
|
From: doug s. <hig...@ho...> - 2013-05-27 22:56:53
|
>>> I changed to integer mouse coordinates, intercepted earlier so they apply to statusbarHud as well as navigation, clicking and picking. >>> . >>> To do this I changed the linux mouse/keyboard handling code and did not verify it on a linux system ** please verify** >> freewrl -R ../freewrl/tests/1.wrl >> >> I do see a file being saved here @ recording/1_wrl.fwplay but I don't >> think the mouse movements and clicks are being recorded. >> The keyboard keystrokes seem to be collected but in a weird way I'm not >> sure I understand. >> >> Also, I see some funny characters ... >> >> 22 1369662229.734600 "�,2,/,2," "" >> 23 1369662230.235250 "/,3,�,3," "" >> 24 1369662230.735990 "" "" >> 25 1369662231.236659 "" "" >> 26 1369662231.737341 "d,2,d,3," "" >> > very interesting on the keystrokes - I don't know what's going on. > With the mouse, I forgot to set if(1) and if(0) in handle_Xevents in MainLoop.c around line 1424 and 1456 - OK I did it now and checked it in. > If you update, re-build and re-run you should see the mouse coords. , Paulo, I got the testing to run a bit in Ubuntu, with wrong snapshot naming: """ fixture/1_wrl_24.snap do Snapshot ... cannot open temp file (freewrl_tmp/fixture/1_wrl_24.snap.0001.rgb) for writing fixture/1_wrl_25.snap """ It's supposed to be fixture/1_wrl_24.snap or -now that I know what snap meant- preferably .rgb. I can look at that tomorrow. And I got something in the recordings/1_wrl.fwplay ... 20 1369694120.450172 "" "6,0,299,399,0;6,0,297,352,0;" 21 1369694120.950736 "" "6,0,290,326,0;" 22 1369694121.452277 "" "" 23 1369694121.953646 "" "" 24 1369694122.456532 "x,2," "" 25 1369694122.956802 "x,3," "" 26 1369694123.462436 "" "" ,,, which shows I'm getting keyboard and mouse now. I didn't get the funny keyboard characters. Is that something to do with language packs in the OS? If so there's something we did for text nodes that convert UTF8 to 32 bit chars -Component_Text.c L.721- so it might need a function to convert back from 32 bit to UTF8 2byte sequence? -Doug |
|
From: doug s. <hig...@ho...> - 2013-05-28 16:56:01
|
MainLoop.c L.1665 in render() I'd like FREEWRL_STEREO_RENDERING to be defined in my linux build. I can hack the .c code to define it, and I see sidebyside and anaglyph rendering work well, toggled by the statsbarHud options page. I know little about the linux build system. I did do ./configure --with-statusbar=hud and that worked. Q. How do I do define FREEWRL_STEREO_RENDERING during the linux build process? Thanks, Doug |
|
From: Paulo E. C. <pau...@gm...> - 2013-05-28 17:33:42
|
On 27/05/13 23:56, doug sanden wrote: > which shows I'm getting keyboard and mouse now. I didn't get the funny keyboard characters. Is that something to do with language packs in the OS? If so there's something we did for text nodes that convert UTF8 to 32 bit chars -Component_Text.c L.721- so it might need a function to convert back from 32 bit to UTF8 2byte sequence? I figured where the funny chars are coming from... It's from key modifiers like ALT,CTRL,SHIFT etc... And I don't see any handling of these modifiers within /handle_Xevents/, The reason why they show up as "funky" chars in my screen has to do with this: http://stackoverflow.com/questions/1688989/xlookupstring-returning-a-utf-8-code-latin-1-to-utf-8 tl;dr - According to the documentation, /XLookupString/ is supposed to return a Latin-1 code. I suppose that as long as there is no important key combi that might use any of these modifiers it should be allright... Apart from that, it is actually starting to look quite good in terms of potential functionality... |
|
From: Paulo E. C. <pau...@gm...> - 2013-05-28 17:54:58
|
On 28/05/13 17:55, doug sanden wrote: > I'd like FREEWRL_STEREO_RENDERING to be defined in my linux build. I can hack the .c code to define it, and I see sidebyside and anaglyph rendering work well, toggled by the statsbarHud options page. I know little about the linux build system. I did do ./configure --with-statusbar=hud and that worked. > Q. How do I do define FREEWRL_STEREO_RENDERING during the linux build process? Apparently, FREEWRL_STEREO_RENDERING, is only defined in these files: projectfiles_vc10/config.h 273:#define FREEWRL_STEREO_RENDERING 1 projectfiles_vc9/config.h 273:#define FREEWRL_STEREO_RENDERING 1 Which leads me to believe that whoever implemented stereo never implemented the definition of the variable for the linux build system. To achieve that, one needs to create that variable. something like this in configure.ac should do the trick. ------ Cut here----- AC_MY_DEFINE_SWITCH([stereo],[enable stereo (default=off)],off,FREEWRL_STEREO_RENDERING) AM_CONDITIONAL([FREEWRL_STEREO_RENDERING],[test "$sw_stereo" != no]) --------------- After these lines have been added to configure.ac, run /autoreconf/ and afterwards/./configure --help/ should give you an option which starts with "--enable-stereo". Please have a look at what I've done here to add a similar optional switch to generate the Doxygen documentation. https://github.com/pecastro/freewrl/commit/20c2628999457c1a64262b11524fcc805ef853b2#L1R153 |
|
From: doug s. <hig...@ho...> - 2013-05-28 17:58:46
|
> > which shows I'm getting keyboard and mouse now. I didn't get the funny keyboard characters. Is that something to do with language packs in the OS? If so there's something we did for text nodes that convert UTF8 to 32 bit chars -Component_Text.c L.721- so it might need a function to convert back from 32 bit to UTF8 2byte sequence? > > I figured where the funny chars are coming from... > It's from key modifiers like ALT,CTRL,SHIFT etc... > And I don't see any handling of these modifiers within handle_Xevents, > > The reason why they show up as "funky" chars in my screen has to do > with this: > > http://stackoverflow.com/questions/1688989/xlookupstring-returning-a-utf-8-code-latin-1-to-utf-8 > > tl;dr - According to the documentation, XLookupString is supposed to > return a Latin-1 code. > > I suppose that as long as there is no important key combi that might > use any of these modifiers it should be allright... > > Apart from that, it is actually starting to look quite good in terms of > potential functionality... > Paulo, thanks. I haven't got the .rgb file naming worked out yet - I did it wrong in win32, and I want to get them harmonized. Using the ALT,CTRL,SHIFT and other keys I was able to get some funny chars^. So as you say, options: a) convert back&forth to/from UTF8 for recording to the file OR b) just leave them as funny chars if they playback OK -Doug ^It might be nice to go from the int*4 to UTF8 - and we have functions already to go UTF8 to int32, if not too much trouble, and in such a way it works for all OS. Using CTRL, ALT and SHIFT with some other chars I get (in the /recording/1_wrl.fwplay) 15 42523.093000 ",3," "" 16 42523.609000 "" "" 19 42525.109000 "" "" 20 42525.609000 ",2," "" 21 42526.109000 "" "" 22 42526.609000 "" "" 23 42527.125000 "Ý,2,,1,Ý,3,,3," "" 24 42527.625000 "" "" 29 42530.140000 "" "" 30 42530.640000 "" "6,0,419,162,0;" 31 42531.140000 ",3," "" 32 42531.640000 "" "" 33 42532.156000 "" "" 34 42532.656000 ",2," "" 35 42533.156000 "" "" 36 42533.656000 "" "" 37 42534.171000 "" "" 38 42534.671000 "Ü,2,|,1,Ü,3," "" 39 42535.171000 ",3," "" |
|
From: doug s. <hig...@ho...> - 2013-06-01 18:17:19
|
testing I added a commandline option for setting the name of the .fwplay test file: -N or --nametest <string> If the option is omitted, it defaults to 1_wrl.fwplay for a scenefile 1.wrl This is in addition to the other 3 options -R --record (records .fwplay file as you mouse and keyboard in the scene) -F --fixture (plays the .fwplay saving any 'x' snapshots to /fixture/testname.0001.png) -P --playback (same as -F except saves 'x' snapshots to /playback/testname.0001.png) . Benefits: - can use the same scene file for multiple tests without name-clash freewrl 1.wrl -R -N test1 (do some fly navigation tests - generates recording/test1.fwplay) freewrl 1.wrl -R -N test2 (do some examine tests - generates recording/test2.fwplay) . I also added the scenefile name to the .fwplay file format, so it has 2 special lines before the per-frame records start. . test1.fwplay: window_wxh = 600, 400 scenefile = 1.wrl 1 42482.281000 "" "" 2 42482.781000 "" "6,0,491,147,0;" 3 42483.296000 "" "6,0,319,223,0;" ... . In the -N --nametest scenario, a perl script running automated tests needs a list of the .fwplay files. Then it would open the .fwplay and read the scenefile name and set it on the freewrl command line (rather than parsing the name of the scene file from the .fwplay name ie 1_wrl.fwplay -> 1.wrl) freewrl 1.wrl -P -N test1 . If the window width x height is unusual, it could be set on the commandline from perl: freewrl 1.wrl -P -N test1 -g 600x400 . The fixture and playback image files would be named fixture/test1.0001.png playback/test1.0001.png . and if the test went well graphicsmagick gm compare should show the images equal. . -Doug |
|
From: doug s. <hig...@ho...> - 2013-05-28 21:03:26
|
> > I'd like FREEWRL_STEREO_RENDERING to be defined in my linux build. I can hack the .c code to define it, and I see sidebyside and anaglyph rendering work well, toggled by the statsbarHud options page. I know little about the linux build system. I did do ./configure --with-statusbar=hud and that worked. > Q. How do I do define FREEWRL_STEREO_RENDERING during the linux build process? > > > Apparently, FREEWRL_STEREO_RENDERING, is only defined in these files: > > projectfiles_vc10/config.h > 273:#define FREEWRL_STEREO_RENDERING 1 > > projectfiles_vc9/config.h > 273:#define FREEWRL_STEREO_RENDERING 1 > > Which leads me to believe that whoever implemented stereo never > implemented the definition of the variable for the linux build system. > To achieve that, one needs to create that variable. > > something like this in configure.ac should do the trick. > > ------ Cut here----- > AC_MY_DEFINE_SWITCH([stereo],[enable stereo > (default=off)],off,FREEWRL_STEREO_RENDERING) > AM_CONDITIONAL([FREEWRL_STEREO_RENDERING],[test "$sw_stereo" != no]) > --------------- > > After these lines have been added to configure.ac, run autoreconf and > afterwards ./configure --help should give you an option which starts > with "--enable-stereo". Yes - works, and checked in. Thanks Paulo. -Doug > > Please have a look at what I've done here to add a similar optional > switch to generate the Doxygen documentation. > https://github.com/pecastro/freewrl/commit/20c2628999457c1a64262b11524fcc805ef853b2#L1R153 > |
|
From: doug s. <hig...@ho...> - 2013-05-29 02:09:20
|
> I haven't got the .rgb file naming worked out yet - I did it wrong in win32, and I want to get them harmonized. > I made changes to avoid converting the .rgb to .png for testing on linux. But it looks like there's no widthxheight header information being written, and graphicsmagick installed on ubuntu asks for that information if I go gm display 1_wrl.0001.rgb (whereas gm display 1_wrl.0001.png displays the image without having to ask) When I look for an .rgb format, SGI has a .rgb format, and they specify a header. ftp://ftp.sgi.com/graphics/grafica/sgiimage.html http://www.fileformat.info/format/sgiimage/egff.htm and the Snapshot.c code doesn't write a header - just the body, and looks like not in the byte order of the .sgi format. freewrl linux uses imlib2 for reading images. Perhaps imlib2 could be used to save the snapshot images directly to .png, and in such a way that there's no compression, if compression is a problem. http://docs.enlightenment.org/api/imlib2/html/index.html Or during the current image conversion method, specify no compression, if compression is a problem. -Doug |
|
From: doug s. <hig...@ho...> - 2013-05-29 15:09:45
|
>> I haven't got the .rgb file naming worked out yet - I did it wrong in win32, and I want to get them harmonized. >> > I made changes to avoid converting the .rgb to .png for testing on linux. > But it looks like there's no widthxheight header information being written, and graphicsmagick installed on ubuntu asks for that information if I go > gm display 1_wrl.0001.rgb > (whereas gm display 1_wrl.0001.png displays the image without having to ask) > When I look for an .rgb format, SGI has a .rgb format, and they specify a header. > ftp://ftp.sgi.com/graphics/grafica/sgiimage.html > http://www.fileformat.info/format/sgiimage/egff.htm > and the Snapshot.c code doesn't write a header - just the body, and looks like not in the byte order of the .sgi format. > freewrl linux uses imlib2 for reading images. Perhaps imlib2 could be used to save the snapshot images directly to .png, and in such a way that there's no compression, if compression is a problem. > http://docs.enlightenment.org/api/imlib2/html/index.html > Or during the current image conversion method, specify no compression, if compression is a problem. . I'm finding the .pngs show different when using perl compare, but show identical when using the graphicsmagick compare function: . gm compare -metric mse fixture/1_wrl.0001.png playback/1_wrl.0001.png (shows a statistical table with 0.00000 difference) gm compare fixture/1_wrl.0001.png playback/1_wrl.0001.png -file diff.png -highlight-color purple -highlight-style Assign # win32: gm convert diff.bmp win: # linux: gm display diff.png gm display diff.png (shows a .png snapshot image with any different pixels highlighted in purple - no differences) . Hypothesis: the difference is in the .png header information, which may include things like date stamp or name of file, and would show different in a perl file binary compare(,) but not in a gm image compare that compares just the pixel data. . So I'll leave the linux code as it was - converting .rgb to .png. -Doug |
|
From: doug s. <hig...@ho...> - 2013-05-29 17:06:42
|
> . > gm compare -metric mse fixture/1_wrl.0001.png playback/1_wrl.0001.png > (shows a statistical table with 0.00000 difference) > gm compare fixture/1_wrl.0001.png playback/1_wrl.0001.png -file diff.png -highlight-color purple -highlight-style Assign > # win32: gm convert diff.bmp win: > # linux: gm display diff.png > gm display diff.png > (shows a .png snapshot image with any different pixels highlighted in purple - no differences) > . . in win32 I got a gm compare difference when I did freewrl 1.wrl -R -F freewrl 1.wrl -P to generate the fixture while recording. I got a few pixels different. . When I did it in 3 steps: freewrl 1.wrl -R freewrl 1.wrl -F freewrl 1.wrl -P Then the fixture and playback images are identical. . Hypotheses: H0: it has something to do with the cursor, which is over the window during -R H1: random - need to do more tests to see if it happens again . -Doug |
|
From: Ian S. A. <ia...@ae...> - 2013-05-29 19:13:56
|
On 28/05/13 05:03 PM, doug sanden wrote: >> >> I'd like FREEWRL_STEREO_RENDERING to be defined in my linux build. I can hack the .c code to define it, and I see sidebyside and anaglyph rendering work well, toggled by the statsbarHud options page. I know little about the linux build system. I did do ./configure --with-statusbar=hud and that worked. >> Q. How do I do define FREEWRL_STEREO_RENDERING during the linux build process? >> >> >> Apparently, FREEWRL_STEREO_RENDERING, is only defined in these files: >> >> projectfiles_vc10/config.h >> 273:#define FREEWRL_STEREO_RENDERING 1 >> >> projectfiles_vc9/config.h >> 273:#define FREEWRL_STEREO_RENDERING 1 >> >> Which leads me to believe that whoever implemented stereo never >> implemented the definition of the variable for the linux build system. >> To achieve that, one needs to create that variable. >> >> something like this in configure.ac should do the trick. >> >> ------ Cut here----- >> AC_MY_DEFINE_SWITCH([stereo],[enable stereo >> (default=off)],off,FREEWRL_STEREO_RENDERING) >> AM_CONDITIONAL([FREEWRL_STEREO_RENDERING],[test "$sw_stereo" != no]) >> --------------- >> >> After these lines have been added to configure.ac, run autoreconf and >> afterwards ./configure --help should give you an option which starts >> with "--enable-stereo". > Yes - works, and checked in. Thanks Paulo. > -Doug Curious -- is there any particular need for this to ever be off? Or are we using compile-time #ifdefs to do something that should probably be configured at runtime? |
|
From: doug s. <hig...@ho...> - 2013-05-29 19:42:31
|
>>> >>> I'd like FREEWRL_STEREO_RENDERING to be defined in my linux build. I can hack the .c code to define it, and I see sidebyside and anaglyph rendering work well, toggled by the statsbarHud options page. I know little about the linux build system. I did do ./configure --with-statusbar=hud and that worked. >>> Q. How do I do define FREEWRL_STEREO_RENDERING during the linux build process? >>> >>> >>> Apparently, FREEWRL_STEREO_RENDERING, is only defined in these files: >>> >>> projectfiles_vc10/config.h >>> 273:#define FREEWRL_STEREO_RENDERING 1 >>> >>> projectfiles_vc9/config.h >>> 273:#define FREEWRL_STEREO_RENDERING 1 >>> >>> Which leads me to believe that whoever implemented stereo never >>> implemented the definition of the variable for the linux build system. >>> To achieve that, one needs to create that variable. >>> >>> something like this in configure.ac should do the trick. >>> >>> ------ Cut here----- >>> AC_MY_DEFINE_SWITCH([stereo],[enable stereo >>> (default=off)],off,FREEWRL_STEREO_RENDERING) >>> AM_CONDITIONAL([FREEWRL_STEREO_RENDERING],[test "$sw_stereo" != no]) >>> --------------- >>> >>> After these lines have been added to configure.ac, run autoreconf and >>> afterwards ./configure --help should give you an option which starts >>> with "--enable-stereo". >> Yes - works, and checked in. Thanks Paulo. >> -Doug > > > Curious -- is there any particular need for this to ever be off? Or are > we using compile-time #ifdefs to do something that should probably be > configured at runtime? > I'm OK if it's built in / no ifdefs or .configure needed. Shall I? -Doug more.. It's always built in win32. I think during development there was some distaste for it being in the code, or perhaps creating liabilities if someone's eyes going crosseyed as a result. The shutterglasses option just wiggles around harmlessly. The sidebyside needs a screen bigger than your eyebase to be usable, but does no harm on a small screen. The Blackberry playbook Qnx tablet implementation does side-by-side nicely. The analgyph should work no matter what the screen size, although John was saying he found it fiddly on Android. I don't know if there are keyboard commands for all 3 modes, but if the .configure --with-statsubar=hud is used, there's an options button/panel that allows you to toggle / choose stereo mode and set any parameters, and toggle it off when done. So no command line option is needed. I think there are 2 more if()s it has to check per loop if you're not using it and its compiled in. I was honoring the historical #ifdefs by other developers who found the whole stereovision thing distasteful and wanted no part of it. I've seen that reaction before when I gave a seminar on a virtual tour I did of an historical townsite, given to a museum association at their annual meeting. I passed out anaglyph glasses with the DVD and papers. After the class, all the papers and DVDs were taken, but a few anaglyph glasses were left behind. I suspect that people who can't see stereo find it distasteful or humiliating. Which I respect. But perhaps the code now -in it's much cleaner, proven state, with fiducials and eyebase control- perhaps its acceptable to all for default inclusion. In that case, yes we can build it in by default. Summary: it doesn't hurt to always compile it in. Then if you don't want to use it, don't. |