Thread: [Vrmlengine-main] compiling issues
Game engine supporting many 3D/2D formats and graphic effects
Brought to you by:
kambi
Menu
▾
▴
vrmlengine-main
|
From: <da...@la...> - 2009-01-18 04:46:33
|
I have been trying to compile the view3dscene tool from source becouse the 32 bit packages available don't work on my 64 bit ubuntu install (too many dependancies on libraries) I have some structures that I've created with CAD programs I want to do walkthroughs on however I am getting permission denied errors when I try to run the result. I tried running the tests, but they seem to want a bunch f other things available (including the castle game) any pointers? Daivd Lnag |
|
From: Michalis K. <mic...@gm...> - 2009-01-18 06:07:20
|
da...@la... wrote: > I have been trying to compile the view3dscene tool from source becouse the > 32 bit packages available don't work on my 64 bit ubuntu install (too many > dependancies on libraries) > > I have some structures that I've created with CAD programs I want to do walkthroughs on > > however I am getting permission denied errors when I try to run the > result. I tried running the tests, but they seem to want a bunch f other > things available (including the castle game) > > any pointers? > Some tests indeed require other stuff, generally you need a checkout of the full vrmlengine/trunk/ to execute all tests. This is especially true of view3dscene/run_tests.sh test, this depends on actual test files available in parent subdirectories. All tests will fail if you cannot execute the compiled view3dscene anyway... What is the exact error message? Did the compilation went Ok? The normal way to compile is to have view3dscene/ and kambi_vrml_game_engine/ directories as siblings, then "cd view3dscene/" and "./compile.sh". After this, you should be able to execute view3dscene like any other program, by "./view3dscene". What version of the sources (the ones from SVN, or the stable tar.gz releases?), what version of FPC do you use? Michalis |
|
From: <da...@la...> - 2009-01-18 07:16:45
|
On Sun, 18 Jan 2009, Michalis Kamburelis wrote: > da...@la... wrote: >> I have been trying to compile the view3dscene tool from source becouse the >> 32 bit packages available don't work on my 64 bit ubuntu install (too many >> dependancies on libraries) >> >> I have some structures that I've created with CAD programs I want to do walkthroughs on >> >> however I am getting permission denied errors when I try to run the >> result. I tried running the tests, but they seem to want a bunch f other >> things available (including the castle game) >> >> any pointers? >> > > Some tests indeed require other stuff, generally you need a checkout of > the full vrmlengine/trunk/ to execute all tests. This is especially true > of view3dscene/run_tests.sh test, this depends on actual test files > available in parent subdirectories. All tests will fail if you cannot > execute the compiled view3dscene anyway... > > What is the exact error message? Did the compilation went Ok? The normal > way to compile is to have view3dscene/ and kambi_vrml_game_engine/ > directories as siblings, then "cd view3dscene/" and "./compile.sh". > After this, you should be able to execute view3dscene like any other > program, by "./view3dscene". by the way, one other problem that I had was that it looks like one program depends on the results of the other program(s) not only being compiled, but being moved somewhere in the path. I ended up doing a svn checkout of everything and then doing find . -executable -type f |grep -v ".sh$"|while read file; do cp -p $file /usr/src/kambi/bin ;done to get copies of all the executables in one place. > What version of the sources (the ones from SVN, or the stable tar.gz > releases?), what version of FPC do you use? missed the question about fpc. #dpkg -l |grep fpc ii fpc 2.2.0-dfsg1-9ubuntu1 Free Pascal Compiler -- Meta Package > Michalis > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > vrmlengine-main mailing list > vrm...@li... > https://lists.sourceforge.net/lists/listinfo/vrmlengine-main > |
|
From: <da...@la...> - 2009-01-18 07:44:17
|
On Sun, 18 Jan 2009, da...@la... wrote: >> da...@la... wrote: >>> however I am getting permission denied errors when I try to run the >>> result. I tried running the tests, but they seem to want a bunch f other >>> things available (including the castle game) >>> >>> any pointers? >>> >> >> Some tests indeed require other stuff, generally you need a checkout of >> the full vrmlengine/trunk/ to execute all tests. This is especially true >> of view3dscene/run_tests.sh test, this depends on actual test files >> available in parent subdirectories. All tests will fail if you cannot >> execute the compiled view3dscene anyway... >> >> What is the exact error message? Did the compilation went Ok? The normal >> way to compile is to have view3dscene/ and kambi_vrml_game_engine/ >> directories as siblings, then "cd view3dscene/" and "./compile.sh". >> After this, you should be able to execute view3dscene like any other >> program, by "./view3dscene". > > by the way, one other problem that I had was that it looks like one program > depends on the results of the other program(s) not only being compiled, but > being moved somewhere in the path. > > I ended up doing a svn checkout of everything and then doing > find . -executable -type f |grep -v ".sh$"|while read file; do cp -p $file > /usr/src/kambi/bin ;done > to get copies of all the executables in one place. > > > >> What version of the sources (the ones from SVN, or the stable tar.gz >> releases?), what version of FPC do you use? > > missed the question about fpc. > > #dpkg -l |grep fpc > > ii fpc 2.2.0-dfsg1-9ubuntu1 Free > Pascal Compiler -- Meta Package I just noticed the note about a bug with the 64 bit stuff. given that I compiled from SVN that should be working (even with fpc 2.2.0) I'm downloading a newer fpc and will try again with it. David Lang |
|
From: <da...@la...> - 2009-01-18 07:50:31
|
On Sun, 18 Jan 2009, da...@la... wrote: > On Sun, 18 Jan 2009, da...@la... wrote: > >>> da...@la... wrote: >>> >>> What is the exact error message? Did the compilation went Ok? The normal >>> way to compile is to have view3dscene/ and kambi_vrml_game_engine/ >>> directories as siblings, then "cd view3dscene/" and "./compile.sh". >>> After this, you should be able to execute view3dscene like any other >>> program, by "./view3dscene". >> >> by the way, one other problem that I had was that it looks like one program >> depends on the results of the other program(s) not only being compiled, but >> being moved somewhere in the path. >> >> I ended up doing a svn checkout of everything and then doing >> find . -executable -type f |grep -v ".sh$"|while read file; do cp -p $file >> /usr/src/kambi/bin ;done >> to get copies of all the executables in one place. >> >> >> >>> What version of the sources (the ones from SVN, or the stable tar.gz >>> releases?), what version of FPC do you use? >> >> missed the question about fpc. >> >> #dpkg -l |grep fpc >> >> ii fpc 2.2.0-dfsg1-9ubuntu1 Free >> Pascal Compiler -- Meta Package > > I just noticed the note about a bug with the 64 bit stuff. given that I > compiled from SVN that should be working (even with fpc 2.2.0) > > I'm downloading a newer fpc and will try again with it. I did a make clean; make in the game engine directory, then I went to the view3dscene directory and did ./compile.sh the results are: root@dlang-laptop:/usr/src/kambi/view3dscene# ./compile.sh Compiling Release Version Compiling Release Version Warning: You are using the obsolete switch -OG Free Pascal Compiler version 2.2.2 [2008/07/29] for x86_64 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Linux for x86-64 Compiling ../view3dscene/view3dscene.pasprogram Compiling ./opengl/glwindow.pas Compiling ./opengl/glwinmodes.pas Compiling ./opengl/glwinmessages.pas Compiling ./opengl/glwinmodes.pas Compiling ../view3dscene/texturefilters.pas Compiling ../view3dscene/colormodulators.pas Compiling ../view3dscene/v3dscenelights.pas Compiling ../view3dscene/v3dscenefillmode.pas Compiling ../view3dscene/raytracetowindow.pas Compiling ../view3dscene/multinavigators.pas Compiling ../view3dscene/scenechangesunit.pas Compiling ../view3dscene/bgcolors.pas Compiling ../view3dscene/v3dscenecamera.pas Compiling ../view3dscene/v3dsceneconfig.pas Compiling ../view3dscene/v3dsceneblending.pas Compiling ../view3dscene/v3dscenewarnings.pas Compiling ../view3dscene/v3dsceneantialiasing.pas Compiling ../view3dscene/v3dscenescreenshot.pas Compiling ../view3dscene/v3dsceneoptimization.pas Compiling ../view3dscene/v3dsceneshadows.pas Linking ../view3dscene/view3dscene /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_FILE_SYSTEM_ERROR$$LONGWORD': gtk2.pas:(.text+0x104ed): undefined reference to `gtk_file_system_error_quark' /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_TYPE_FILE_INFO$$QWORD': gtk2.pas:(.text+0x10505): undefined reference to `gtk_file_info_get_type' /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_TYPE_FILE_SYSTEM$$QWORD': gtk2.pas:(.text+0x1051d): undefined reference to `gtk_file_system_get_type' /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_TYPE_FILE_FOLDER$$QWORD': gtk2.pas:(.text+0x105b5): undefined reference to `gtk_file_folder_get_type' Error: Error while linking Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/local/bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) root@dlang-laptop:/usr/src/kambi/view3dscene# |
|
From: Michalis K. <mic...@gm...> - 2009-01-18 08:12:47
|
da...@la... wrote: [...] > > I did a make clean; make in the game engine directory, then I went to the > view3dscene directory and did ./compile.sh > > the results are: > [...] > /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function > `GTK2_GTK_TYPE_FILE_FOLDER$$QWORD': > gtk2.pas:(.text+0x105b5): undefined reference to > `gtk_file_folder_get_type' > Error: Error while linking > Fatal: There were 1 errors compiling module, stopping > Fatal: Compilation aborted > Error: /usr/local/bin/ppcx64 returned an error exitcode (normal if you did > not specify a source file to be compiled) > root@dlang-laptop:/usr/src/kambi/view3dscene# > Argh. Ubuntu 8.10 uses GTK 2.14, that broke compatibility with previous versions and removed some functions. This is fixed in FPC now (more details here http://mantis.freepascal.org/view.php?id=11837), unfortunately this fix is only in FPC > 2.2.2 (not stable). To use FPC 2.2.2, you should be able to tell the linker to ignore these undefined references (they are not used by view3dscene anyway, they just get linked because they are declared in FPC gtk2 unit): in compile.sh, add option -k--noinhibit-exec to fpc call, that is make it fpc -dRELEASE @kambi.cfg -k--noinhibit-exec \ ../view3dscene/view3dscene.pasprogram Please tell me if this works, I'll mention it on http://vrmlengine.sourceforge.net/kambi_vrml_game_engine.php#section_fpc_ver then. Sorry about the trouble, such things obviously shouldn't happen... Unfortunately this a GTK and FPC problem, beyond the control of my engine. Michalis |
|
From: <da...@la...> - 2009-01-18 08:21:30
|
On Sun, 18 Jan 2009, Michalis Kamburelis wrote: > da...@la... wrote: > [...] >> >> I did a make clean; make in the game engine directory, then I went to the >> view3dscene directory and did ./compile.sh >> >> the results are: >> > [...] >> /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function >> `GTK2_GTK_TYPE_FILE_FOLDER$$QWORD': >> gtk2.pas:(.text+0x105b5): undefined reference to >> `gtk_file_folder_get_type' >> Error: Error while linking >> Fatal: There were 1 errors compiling module, stopping >> Fatal: Compilation aborted >> Error: /usr/local/bin/ppcx64 returned an error exitcode (normal if you did >> not specify a source file to be compiled) >> root@dlang-laptop:/usr/src/kambi/view3dscene# >> > > Argh. Ubuntu 8.10 uses GTK 2.14, that broke compatibility with previous > versions and removed some functions. This is fixed in FPC now (more > details here http://mantis.freepascal.org/view.php?id=11837), > unfortunately this fix is only in FPC > 2.2.2 (not stable). > > To use FPC 2.2.2, you should be able to tell the linker to ignore these > undefined references (they are not used by view3dscene anyway, they just > get linked because they are declared in FPC gtk2 unit): in compile.sh, > add option > > -k--noinhibit-exec > > to fpc call, that is make it > > fpc -dRELEASE @kambi.cfg -k--noinhibit-exec \ > ../view3dscene/view3dscene.pasprogram > > Please tell me if this works, I'll mention it on > http://vrmlengine.sourceforge.net/kambi_vrml_game_engine.php#section_fpc_ver > then. no go. I re-pulled everything from svn after your prior message ./compile.sh Compiling Release Version Compiling Release Version Warning: You are using the obsolete switch -OG Free Pascal Compiler version 2.2.2 [2008/07/29] for x86_64 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Linux for x86-64 Compiling ../view3dscene/view3dscene.pasprogram Compiling ./opengl/glwindow.pas Linking ../view3dscene/view3dscene /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_FILE_SYSTEM_ERROR$$LONGWORD': gtk2.pas:(.text+0x104ed): undefined reference to `gtk_file_system_error_quark' /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_TYPE_FILE_INFO$$QWORD': gtk2.pas:(.text+0x10505): undefined reference to `gtk_file_info_get_type' /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_TYPE_FILE_SYSTEM$$QWORD': gtk2.pas:(.text+0x1051d): undefined reference to `gtk_file_system_get_type' /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_TYPE_FILE_FOLDER$$QWORD': gtk2.pas:(.text+0x105b5): undefined reference to `gtk_file_folder_get_type' 24455 lines compiled, 2.4 sec 1 warning(s) issued root@dlang-laptop:/usr/src/kambi/view3dscene# cat compile.sh #! /bin/sh set -eu # This is automatically generated script that should compile # all programs in this archive. It simply calls FPC # with proper command-line options. # # We must do cd ../kambi_vrml_game_engine/ (and call FPC from that directory) # because kambi.cfg file is there and it contains paths relative # to that directory. cd ../kambi_vrml_game_engine/ # This program uses GLWindow unit. GLWindow unit may be compiled # with various back-ends (e.g. under Unices two most useful back-ends # are XLIB and GTK). To make sure that compilation of this program # will produce exactly what you need, below we make sure that # unit GLWindow will be *always* *rebuild*. # # Of course this means that compilation time will suffer a little, # since GLWindow unit will be possibly rebuild without any real need. # Comment out line below if you want. rm -f opengl/glwindow.o \ opengl/glwindow.ppu \ opengl/GLWindow.o \ opengl/GLWindow.ppu fpc -dRELEASE @kambi.cfg -k--noinhibit-exec ../view3dscene/view3dscene.pasprogram > > Sorry about the trouble, such things obviously shouldn't happen... > Unfortunately this a GTK and FPC problem, beyond the control of my engine. I'm just happy to have you responding with fixes so quickly ;-) |
|
From: <da...@la...> - 2009-01-18 08:26:33
|
On Sun, 18 Jan 2009, da...@la... wrote: >> >> To use FPC 2.2.2, you should be able to tell the linker to ignore these >> undefined references (they are not used by view3dscene anyway, they just >> get linked because they are declared in FPC gtk2 unit): in compile.sh, >> add option >> >> -k--noinhibit-exec >> >> to fpc call, that is make it >> >> fpc -dRELEASE @kambi.cfg -k--noinhibit-exec \ >> ../view3dscene/view3dscene.pasprogram >> >> Please tell me if this works, I'll mention it on >> http://vrmlengine.sourceforge.net/kambi_vrml_game_engine.php#section_fpc_ver >> then. > > no go. I re-pulled everything from svn after your prior message > I may have spoken too soon. It gave the errors, but still produced a binary to run. now I just need to play with it and see if I can figure out how to work it :-) David Lang |
|
From: Michalis K. <mic...@gm...> - 2009-01-18 08:42:52
|
da...@la... wrote: > > I may have spoken too soon. It gave the errors, but still produced a > binary to run. > > now I just need to play with it and see if I can figure out how to work it > :-) > Looks like we both write our mails too fast :) Glad it worked. Added a notes about this to http://vrmlengine.sourceforge.net/kambi_vrml_game_engine.php#section_fpc_ver Michalis |
|
From: Michalis K. <mic...@gm...> - 2009-01-18 07:55:16
|
da...@la... wrote: > > by the way, one other problem that I had was that it looks like one > program depends on the results of the other program(s) not only being > compiled, but being moved somewhere in the path. The view3dscene/run_tests.sh? Yeah, it did require view3dscene on the $PATH. Fixed view3dscene/run_tests.sh in SVN now, it will now use view3dscene compiled in current dir if available. > > I ended up doing a svn checkout of everything and then doing > find . -executable -type f |grep -v ".sh$"|while read file; do cp -p $file /usr/src/kambi/bin ;done > to get copies of all the executables in one place. This shouldn't be needed, only view3dscene was needed for view3dscene/run_tests.sh. BTW, this showed me that there are many files committed with executable bit accidentally on (a result of working long time ago on FAT filesystem). Fixed in SVN now, so "find . -executable -type f" will find only real executables. >> What version of the sources (the ones from SVN, or the stable tar.gz >> releases?), what version of FPC do you use? > > missed the question about fpc. > > #dpkg -l |grep fpc > > ii fpc 2.2.0-dfsg1-9ubuntu1 > Free Pascal Compiler -- Meta Package > Ah, and that's the reason of your problems. See http://vrmlengine.sourceforge.net/kambi_vrml_game_engine.php#section_fpc_ver : FPC 2.2.0 has a terrible bug in OpenGL unit, that will cause all programs on non-32-bit platforms to fail with access violations whenever they query OpenGL about extensions. Solutions: 1. Place -Fu<path-where-you-downloaded-vrmlengine>kambi_vrml_game_engine/opengl/x86_64/ at the beginning of your ~/.fpc.cfg (or /etc/fpc.cfg, whichever exists), and recompile all (doing "make clean" inside "kambi_vrml_game_engine/" directory, and then compiling view3dscene again should do the trick). For safety, you can even temporarily remove/rename the files /usr/lib/fpc/2.2.0/units/x86_64-linux/opengl/glext.o /usr/lib/fpc/2.2.0/units/x86_64-linux/opengl/glext.ppu before recompiling, to make sure FPC doesn't use buggy versions of this unit. 2. Or just install FPC 2.2.2 from http://www.freepascal.org/, the bug is fixed there. Michalis |
|
From: <da...@la...> - 2009-01-18 08:02:59
|
On Sun, 18 Jan 2009, Michalis Kamburelis wrote: > da...@la... wrote: >> >> by the way, one other problem that I had was that it looks like one >> program depends on the results of the other program(s) not only being >> compiled, but being moved somewhere in the path. > > The view3dscene/run_tests.sh? Yeah, it did require view3dscene on the > $PATH. Fixed view3dscene/run_tests.sh in SVN now, it will now use > view3dscene compiled in current dir if available. > >> >> I ended up doing a svn checkout of everything and then doing >> find . -executable -type f |grep -v ".sh$"|while read file; do cp -p $file /usr/src/kambi/bin ;done >> to get copies of all the executables in one place. > > This shouldn't be needed, only view3dscene was needed for > view3dscene/run_tests.sh. there were several other binaries that were needed. I don't remember where all of them were. I did the first couple manually, then did the find when I was still getting problems. > BTW, this showed me that there are many files committed with executable > bit accidentally on (a result of working long time ago on FAT > filesystem). Fixed in SVN now, so "find . -executable -type f" will find > only real executables. > >>> What version of the sources (the ones from SVN, or the stable tar.gz >>> releases?), what version of FPC do you use? >> >> missed the question about fpc. >> >> #dpkg -l |grep fpc >> >> ii fpc 2.2.0-dfsg1-9ubuntu1 >> Free Pascal Compiler -- Meta Package >> > > Ah, and that's the reason of your problems. See > http://vrmlengine.sourceforge.net/kambi_vrml_game_engine.php#section_fpc_ver > : FPC 2.2.0 has a terrible bug in OpenGL unit, that will cause all > programs on non-32-bit platforms to fail with access violations whenever > they query OpenGL about extensions. > > Solutions: > > 1. Place > > -Fu<path-where-you-downloaded-vrmlengine>kambi_vrml_game_engine/opengl/x86_64/ > > at the beginning of your ~/.fpc.cfg (or /etc/fpc.cfg, whichever exists), > and recompile all (doing "make clean" inside "kambi_vrml_game_engine/" > directory, and then compiling view3dscene again should do the trick). > > For safety, you can even temporarily remove/rename the files > /usr/lib/fpc/2.2.0/units/x86_64-linux/opengl/glext.o > /usr/lib/fpc/2.2.0/units/x86_64-linux/opengl/glext.ppu > before recompiling, to make sure FPC doesn't use buggy versions of this > unit. > > 2. Or just install FPC 2.2.2 from http://www.freepascal.org/, the bug is > fixed there. as per the other messages, going to fpc 2.2.2 doesn't seem to be working well. David Lang |
|
From: Michalis K. <mic...@gm...> - 2009-01-18 08:32:18
|
da...@la... wrote: > > there were several other binaries that were needed. I don't remember where > all of them were. I did the first couple manually, then did the find when > I was still getting problems. Ah yes, stringoper from engine tools is also needed on the $PATH. Admittedly, view3dscene/run_tests.sh is just not a trivial test to use. I added comments about them at the beginning of view3dscene/run_tests.sh. > no go. I re-pulled everything from svn after your prior message [...] > /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function > `GTK2_GTK_TYPE_FILE_FOLDER$$QWORD': > gtk2.pas:(.text+0x105b5): undefined reference to > `gtk_file_folder_get_type' > 24455 lines compiled, 2.4 sec > 1 warning(s) issued It showed the "undefined reference" problems, but seemingly ignored them (as indicated by "1 warning(s) issued" and no further FPC complains). I would hope that it compiled a working view3dscene executable now --- can you check (look at it's creation time, try to run it...). Michalis |
|
From: <da...@la...> - 2009-01-18 08:38:36
|
On Sun, 18 Jan 2009, Michalis Kamburelis wrote: >> >> there were several other binaries that were needed. I don't remember where >> all of them were. I did the first couple manually, then did the find when >> I was still getting problems. > > Ah yes, stringoper from engine tools is also needed on the $PATH. > Admittedly, view3dscene/run_tests.sh is just not a trivial test to use. > I added comments about them at the beginning of view3dscene/run_tests.sh. > >> no go. I re-pulled everything from svn after your prior message > [...] > >> /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function >> `GTK2_GTK_TYPE_FILE_FOLDER$$QWORD': >> gtk2.pas:(.text+0x105b5): undefined reference to >> `gtk_file_folder_get_type' >> 24455 lines compiled, 2.4 sec >> 1 warning(s) issued > > It showed the "undefined reference" problems, but seemingly ignored them > (as indicated by "1 warning(s) issued" and no further FPC complains). I > would hope that it compiled a working view3dscene executable now --- can > you check (look at it's creation time, try to run it...). it is running, thanks. one problem I am having. I am trying to import a 3ds file of a house design and it seems to be putting the house on it's side David Lang |
|
From: Michalis K. <mic...@gm...> - 2009-01-18 08:51:44
|
da...@la... wrote: [...] > > it is running, thanks. > > one problem I am having. I am trying to import a 3ds file of a house > design and it seems to be putting the house on it's side > If the 3ds file doesn't have a camera defined: The default up vector is +Y (I know, I personally prefer +Z too, but VRML/X3D generally suggest using +Y, so for many VRML/X3D models default +Y is better). You can easily rotate the scene in Examine mode, or jump to viewpoint in Walk mode with up = +Z by menu "Navigation -> Jump to viewpoint -> Calculated viewpoint to see the whole scene (+Z up)". If the 3ds file has camera defined, then this is a bug, can you send me the faulty 3ds file (or report a bug and attach the file, http://sourceforge.net/tracker/?group_id=200653&atid=974391). (I'm going to sleep now, so my next answer will not come so quick :) Regards, Michalis |
|
From: <da...@la...> - 2009-01-18 08:53:25
|
On Sun, 18 Jan 2009, Michalis Kamburelis wrote: > da...@la... wrote: > [...] >> >> it is running, thanks. >> >> one problem I am having. I am trying to import a 3ds file of a house >> design and it seems to be putting the house on it's side >> > > If the 3ds file doesn't have a camera defined: > > The default up vector is +Y (I know, I personally prefer +Z too, but > VRML/X3D generally suggest using +Y, so for many VRML/X3D models default > +Y is better). You can easily rotate the scene in Examine mode, or jump > to viewpoint in Walk mode with up = +Z by menu "Navigation -> Jump to > viewpoint -> Calculated viewpoint to see the whole scene (+Z up)". > > If the 3ds file has camera defined, then this is a bug, can you send me > the faulty 3ds file (or report a bug and attach the file, > http://sourceforge.net/tracker/?group_id=200653&atid=974391). > > (I'm going to sleep now, so my next answer will not come so quick :) > Regards, > Michalis no cameras defined, the files are at http://vrml.lang.hm/vrml David Lang |
|
From: <da...@la...> - 2009-01-18 09:03:49
|
On Sun, 18 Jan 2009, da...@la... wrote: > On Sun, 18 Jan 2009, Michalis Kamburelis wrote: > >> da...@la... wrote: >> [...] >>> >>> it is running, thanks. >>> >>> one problem I am having. I am trying to import a 3ds file of a house >>> design and it seems to be putting the house on it's side >>> >> >> If the 3ds file doesn't have a camera defined: >> >> The default up vector is +Y (I know, I personally prefer +Z too, but >> VRML/X3D generally suggest using +Y, so for many VRML/X3D models default >> +Y is better). You can easily rotate the scene in Examine mode, or jump >> to viewpoint in Walk mode with up = +Z by menu "Navigation -> Jump to >> viewpoint -> Calculated viewpoint to see the whole scene (+Z up)". >> >> If the 3ds file has camera defined, then this is a bug, can you send me >> the faulty 3ds file (or report a bug and attach the file, >> http://sourceforge.net/tracker/?group_id=200653&atid=974391). >> >> (I'm going to sleep now, so my next answer will not come so quick :) >> Regards, >> Michalis > > no cameras defined, the files are at http://vrml.lang.hm/vrml is there a way to define how high above the surface the camera is? David Lang |
|
From: Michalis K. <mic...@gm...> - 2009-01-18 17:44:07
|
da...@la... wrote: > > no cameras defined, the files are at http://vrml.lang.hm/vrml > Ok, looking at both files there (kadota.3ds and kadota-camera.3ds), there indeed seems no camera defined. So behavior of view3dscene seems correct, like said menu "Navigation -> Jump to viewpoint -> Calculated viewpoint to see the whole scene (+Z up)" gets you in somewhat good position. > is there a way to define how high above the surface the camera is? In VRML/X3D, you can define this (and much more). There's no way to encode it in 3ds file (if you know where such info can be found in 3ds format, please tell --- as far as I know, nowhere...). You can convert your 3ds files to VRML ("File -> Save as VRML"), then open the resulting kadota.wrl file in any text editor and add there VRML/X3D nodes specifying camera properties. Desired height above the ground is the second number of NavigationInfo.avatarSize field. You can read VRML 97 or X3D specifications to get a glimpse of all parameters allowed (although I do not handle some newer X3D parameters), see e.g.: http://www.web3d.org/x3d/specifications/vrml/ISO-IEC-14772-VRML97/part1/nodesRef.html#Viewpoint http://www.web3d.org/x3d/specifications/vrml/ISO-IEC-14772-VRML97/part1/nodesRef.html#NavigationInfo For example, check out this file: http://michalis.ii.uni.wroc.pl/~michalis/tmp/kadota.wrl.gz It's your kadota.3ds, converted to VRML, and with added by hand NavigationInfo and PerspectiveCamera at the beginning. (PerspectiveCamera content generated by menu item "Console -> Print Current Camera Node (VRML 1.0)".) As you can see, this way we specify default camera parameters, position, moving speed, even the fact that by default view3dscene should enter "Walk" mode with collisions and gravity. Michalis |
|
From: <da...@la...> - 2009-01-19 00:14:38
|
On Sun, 18 Jan 2009, Michalis Kamburelis wrote: > da...@la... wrote: >> >> no cameras defined, the files are at http://vrml.lang.hm/vrml >> > > Ok, looking at both files there (kadota.3ds and kadota-camera.3ds), > there indeed seems no camera defined. So behavior of view3dscene seems > correct, like said menu "Navigation -> Jump to > viewpoint -> Calculated viewpoint to see the whole scene (+Z up)" gets > you in somewhat good position. yes, that gets me close to useable. >> is there a way to define how high above the surface the camera is? > > In VRML/X3D, you can define this (and much more). There's no way to > encode it in 3ds file (if you know where such info can be found in 3ds > format, please tell --- as far as I know, nowhere...). You can convert > your 3ds files to VRML ("File -> Save as VRML"), then open the resulting > kadota.wrl file in any text editor and add there VRML/X3D nodes > specifying camera properties. > > Desired height above the ground is the second number of > NavigationInfo.avatarSize field. You can read VRML 97 or X3D > specifications to get a glimpse of all parameters allowed (although I do > not handle some newer X3D parameters), see e.g.: > http://www.web3d.org/x3d/specifications/vrml/ISO-IEC-14772-VRML97/part1/nodesRef.html#Viewpoint > http://www.web3d.org/x3d/specifications/vrml/ISO-IEC-14772-VRML97/part1/nodesRef.html#NavigationInfo I will look through this. it would be very useful if there was a way to move this in the program (insert/delete let you move vertically with gravity turned off) in playing around with this and the kadota-land.3ds file (now on my site) I sometimes end up with the camera eye level a foot or so above ground level and sometimes around 9 feet above ground level it would also be useful if there was a way to change the units in the display from meters to feet for the on-screen displays. > For example, check out this file: > > http://michalis.ii.uni.wroc.pl/~michalis/tmp/kadota.wrl.gz > > It's your kadota.3ds, converted to VRML, and with added by hand > NavigationInfo and PerspectiveCamera at the beginning. > (PerspectiveCamera content generated by menu item "Console -> Print > Current Camera Node (VRML 1.0)".) As you can see, this way we specify > default camera parameters, position, moving speed, even the fact that by > default view3dscene should enter "Walk" mode with collisions and gravity. thanks. David Lang |
|
From: Michalis K. <mic...@gm...> - 2009-01-20 00:29:09
|
da...@la... wrote: > > it would be very useful if there was a way to move this in the program > (insert/delete let you move vertically with gravity turned off) Hm, good idea. I added this as Ctrl+Insert, Ctrl+Delete. (At first I wondered whether to just redefine insert/delete for this when gravity is off, but this doesn't feel good on models where you're often outside the bbox of the scene.) I also added "Avatar height", "current height above the ground" on status text in Walk mode, this should be helpful now. Note that current height above the ground varies compared to "Avatar height", due to head bobbing and sometimes due to camera radius (colliding of steep stairs). "Avatar height" (this is exactly what was set by NavigationInfo.avatarSize[1]) is usually slightly larger than "current height" when standing still, as then head bobbing makes you go a little down then. (I think I'll make some extentions to NavigationInfo to control the amount of head-bobbing; but I'm getting off-topic..). > > in playing around with this and the kadota-land.3ds file (now on my site) > I sometimes end up with the camera eye level a foot or so above ground > level and sometimes around 9 feet above ground level When there's no NavigationInfo.avatarSize (or when the file is not VRML/X3D) then default height above the scene is calculated, based on scene bounding box size. (But it should of course stay constant for the same scene --- if it's not, you got a bug, please say on which viewpoints you get different levels above the ground, I'll investigate). > > it would also be useful if there was a way to change the units in the > display from meters to feet for the on-screen displays. I'm unsure about this feature --- I mean, once I start thinking different units of distance, all hell breaks loose and interface gets cluttered, as far as I'm concerned... My current approach is to never talk about "meters" or anything --- what we display are just units within the 3D file. You can always scale your whole model, to make your 3D model "unit" correspond to meter, feet or whatever you like... BTW, one important thing: in previous mail I forgot that you can do the trick with adding NavigationInfo and Viewpoint much easier, without explicitly converting your 3ds file to VRML. You can inline 3ds files inside VRML, which means that you can write VRML file like attached (also an example how you can scale your model), place it in the same dir as kadota.3ds and you're done. The nice thing about this is that you can freely re-export your 3ds file, and it stays separate from VRML-specific features you write. Michalis |
|
From: <da...@la...> - 2009-01-20 02:19:24
|
On Tue, 20 Jan 2009, Michalis Kamburelis wrote: > da...@la... wrote: >> >> it would be very useful if there was a way to move this in the program >> (insert/delete let you move vertically with gravity turned off) > > Hm, good idea. I added this as Ctrl+Insert, Ctrl+Delete. (At first I > wondered whether to just redefine insert/delete for this when gravity is > off, but this doesn't feel good on models where you're often outside the > bbox of the scene.) > > I also added "Avatar height", "current height above the ground" on > status text in Walk mode, this should be helpful now. thanks. > Note that current height above the ground varies compared to "Avatar > height", due to head bobbing and sometimes due to camera radius > (colliding of steep stairs). "Avatar height" (this is exactly what was > set by NavigationInfo.avatarSize[1]) is usually slightly larger than > "current height" when standing still, as then head bobbing makes you go > a little down then. > > (I think I'll make some extentions to NavigationInfo to control the > amount of head-bobbing; but I'm getting off-topic..). > >> >> in playing around with this and the kadota-land.3ds file (now on my site) >> I sometimes end up with the camera eye level a foot or so above ground >> level and sometimes around 9 feet above ground level > > When there's no NavigationInfo.avatarSize (or when the file is not > VRML/X3D) then default height above the scene is calculated, based on > scene bounding box size. (But it should of course stay constant for the > same scene --- if it's not, you got a bug, please say on which > viewpoints you get different levels above the ground, I'll investigate). now that you mention it, I think it's about a foot above ground for the model of the house by itself, and about 9 feet above ground for the house with the terrain around it ( a much larger bounding box) >> it would also be useful if there was a way to change the units in the >> display from meters to feet for the on-screen displays. > > I'm unsure about this feature --- I mean, once I start thinking > different units of distance, all hell breaks loose and interface gets > cluttered, as far as I'm concerned... My current approach is to never > talk about "meters" or anything --- what we display are just units > within the 3D file. I believe the units are in meters by default. > You can always scale your whole model, to make your 3D model "unit" > correspond to meter, feet or whatever you like... hmm, I'll consider it, but that would trip me up when I work on the model with other tools and external objects. > BTW, one important thing: in previous mail I forgot that you can do the > trick with adding NavigationInfo and Viewpoint much easier, without > explicitly converting your 3ds file to VRML. You can inline 3ds files > inside VRML, which means that you can write VRML file like attached > (also an example how you can scale your model), place it in the same dir > as kadota.3ds and you're done. The nice thing about this is that you can > freely re-export your 3ds file, and it stays separate from VRML-specific > features you write. thanks. David Lang |
|
From: <da...@la...> - 2009-01-20 02:35:19
|
On Mon, 19 Jan 2009, da...@la... wrote: > On Tue, 20 Jan 2009, Michalis Kamburelis wrote: > >> da...@la... wrote: >>> >>> it would be very useful if there was a way to move this in the program >>> (insert/delete let you move vertically with gravity turned off) >> >> Hm, good idea. I added this as Ctrl+Insert, Ctrl+Delete. (At first I >> wondered whether to just redefine insert/delete for this when gravity is >> off, but this doesn't feel good on models where you're often outside the >> bbox of the scene.) >> >> I also added "Avatar height", "current height above the ground" on >> status text in Walk mode, this should be helpful now. > > thanks. trying to compile the svn checkout produces the following errors. I checked out the game engine and compiled it without a problem. David Lang root@dlang-laptop:/usr/src/kambi/view3dscene# ./compile.sh Compiling Release Version Compiling Release Version Warning: You are using the obsolete switch -OG Free Pascal Compiler version 2.2.2 [2008/07/29] for x86_64 Copyright (c) 1993-2008 by Florian Klaempfl Target OS: Linux for x86-64 Compiling ../view3dscene/view3dscene.pasprogram Compiling ./opengl/glwindow.pas Linking ../view3dscene/view3dscene /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_FILE_SYSTEM_ERROR$$LONGWORD': gtk2.pas:(.text+0x104ed): undefined reference to `gtk_file_system_error_quark' /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_TYPE_FILE_INFO$$QWORD': gtk2.pas:(.text+0x10505): undefined reference to `gtk_file_info_get_type' /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_TYPE_FILE_SYSTEM$$QWORD': gtk2.pas:(.text+0x1051d): undefined reference to `gtk_file_system_get_type' /usr/local/lib/fpc/2.2.2/units/x86_64-linux/gtk2/gtk2.o: In function `GTK2_GTK_TYPE_FILE_FOLDER$$QWORD': gtk2.pas:(.text+0x105b5): undefined reference to `gtk_file_folder_get_type' Error: Error while linking Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/local/bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) root@dlang-laptop:/usr/src/kambi/view3dscene# |
|
From: <da...@la...> - 2009-01-20 02:42:48
|
On Mon, 19 Jan 2009, da...@la... wrote: > > On Mon, 19 Jan 2009, da...@la... wrote: > >> On Tue, 20 Jan 2009, Michalis Kamburelis wrote: >> >>> da...@la... wrote: >>>> >>>> it would be very useful if there was a way to move this in the program >>>> (insert/delete let you move vertically with gravity turned off) >>> >>> Hm, good idea. I added this as Ctrl+Insert, Ctrl+Delete. (At first I >>> wondered whether to just redefine insert/delete for this when gravity is >>> off, but this doesn't feel good on models where you're often outside the >>> bbox of the scene.) >>> >>> I also added "Avatar height", "current height above the ground" on >>> status text in Walk mode, this should be helpful now. >> >> thanks. > > trying to compile the svn checkout produces the following errors. never mind, this was the -k--noinhibit-exec item in compile.sh. doing a svn checkout reverted it back. is this something that could be put into the upstream version? or will it cause grief for other things. David Lang |
|
From: Michalis K. <mic...@gm...> - 2009-01-20 02:45:36
|
da...@la... wrote: > > trying to compile the svn checkout produces the following errors. > Hm, these are the same errors as before? Add -k--noinhibit-exec to FPC call inside compile.sh. (I cannot add this workaround inside the compile.sh script in SVN, as this may hide real errors in other cases, and people would be confused anyway by linker warnings... You'll have to live with this local modification of compile.sh script on your disc (until FPC 2.2.4 release, which should be Really Soon). If you'll update from SVN, it will keep your local modifications, so this shouldn't be too troublesome.) Alternatively, you can add -k--noinhibit-exec line to your ~/.fpc.cfg or /etc/fpc.cfg (whichever exists). Just be sure to remove it once new FPC will be released, as this is really a dirty workaround. > I checked out the game engine and compiled it without a problem. > You mean "make" inside kambi_vrml_game_engine? This works, because it doesn't do any linking (it only compiles units). Something like "make examples" should fail with the same errors, on all programs using GTK2. Michalis |
|
From: <da...@la...> - 2009-01-20 02:46:28
|
On Tue, 20 Jan 2009, Michalis Kamburelis wrote: > da...@la... wrote: >> >> it would be very useful if there was a way to move this in the program >> (insert/delete let you move vertically with gravity turned off) > > Hm, good idea. I added this as Ctrl+Insert, Ctrl+Delete. (At first I > wondered whether to just redefine insert/delete for this when gravity is > off, but this doesn't feel good on models where you're often outside the > bbox of the scene.) > > I also added "Avatar height", "current height above the ground" on > status text in Walk mode, this should be helpful now. > > Note that current height above the ground varies compared to "Avatar > height", due to head bobbing and sometimes due to camera radius > (colliding of steep stairs). "Avatar height" (this is exactly what was > set by NavigationInfo.avatarSize[1]) is usually slightly larger than > "current height" when standing still, as then head bobbing makes you go > a little down then. > > (I think I'll make some extentions to NavigationInfo to control the > amount of head-bobbing; but I'm getting off-topic..). this lets me increase the avatar height, but it won't reduce it below the default. David Lang |
|
From: Michalis K. <mic...@gm...> - 2009-01-20 03:28:29
|
da...@la... wrote: > On Tue, 20 Jan 2009, Michalis Kamburelis wrote: > >> da...@la... wrote: >>> it would be very useful if there was a way to move this in the program >>> (insert/delete let you move vertically with gravity turned off) >> Hm, good idea. I added this as Ctrl+Insert, Ctrl+Delete. (At first I >> wondered whether to just redefine insert/delete for this when gravity is >> off, but this doesn't feel good on models where you're often outside the >> bbox of the scene.) >> >> I also added "Avatar height", "current height above the ground" on >> status text in Walk mode, this should be helpful now. >> >> Note that current height above the ground varies compared to "Avatar >> height", due to head bobbing and sometimes due to camera radius >> (colliding of steep stairs). "Avatar height" (this is exactly what was >> set by NavigationInfo.avatarSize[1]) is usually slightly larger than >> "current height" when standing still, as then head bobbing makes you go >> a little down then. >> >> (I think I'll make some extentions to NavigationInfo to control the >> amount of head-bobbing; but I'm getting off-topic..). > > this lets me increase the avatar height, but it won't reduce it below the > default. > Fixed (to some extent). Some background why this happens, and why it will always happen to some extent: There's a safety check when lowering avatar height, it cannot go below something like 1.01 * CameraRadius / (0.5 * (1 - 0.1)) ~ 2 * CameraRadius This is deliberate, to allow avatar height cooperate fine, even with head bobbing and crouching (that's the source of various consts above). This check is necessary, you really do not want to have height < radius (as then avatar would be "floating" on his radius, continously trying to fall on the ground... strange effect, definitely not desired). On the other hand, when no NavigationInfo is specified, the default avatar height was =~ 2 * camera radius. So it happened to be actually the minimum allowed avatar height. What I did was to lower default camera radius calculation by 2, and raise default avatar height by 2, so default avatar height is now roughly the same but you have some space to decrease it. There is still some limit, as camera radius must limit avatar height... And default camera radius cannot be too small (or depth buffer errors start to occur, especially on worse OpenGL drivers). IOW: you can now decrease avatar height at runtime, but there's still some limit, determined from camera radius. Dynamically changing camera radius may be implemented, but later. For now, you can always use NavigationInfo to decrease camera radius (the first number in avatarSize), then you'll be able to decrease avatar height more (at the cost of depth precision at some point). Michalis |
Thanks for helping keep SourceForge clean.
X