vrmlengine-main Mailing List for Kambi VRML game engine
Game engine supporting many 3D/2D formats and graphic effects
Brought to you by:
kambi
You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2009 |
Jan
(33) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Michalis K. <mic...@gm...> - 2011-09-23 02:55:42
|
Hi everyone! As announced (http://castle-engine.sourceforge.net/news.php?item=2011-9-23-rename), we rename our engine from "Kambi VRML game engine" to "Castle Game Engine". This also means that various URLs change from "vrmlengine" to "castle-engine". For example, new view3dscene URL is http://castle-engine.sourceforge.net/view3dscene.php . Although I took care to set appropriate redirects everywhere, so actually old links will also continue to work fine, for a long time. Along with the new project name, we also move to new SourceForge 2.0 "Allura" platform. I would like to use new forum / mailing list / wiki and such integrated with Allura, as I think they are quite nice :) So, from now on, *this* mailing list becomes officially closed. Please subscribe and post instead to - new forum on https://sourceforge.net/p/castle-engine/discussion/ - or new mailing list on https://lists.sourceforge.net/lists/listinfo/castle-engine-main - we also have new wiki on https://sourceforge.net/p/castle-engine/wiki/ - we also have new bugtracker on https://sourceforge.net/p/castle-engine/tickets/ All these links are reachable from our http://castle-engine.sourceforge.net/forum.php page. Thank you!, Michalis |
From: Michalis K. <mic...@gm...> - 2011-08-05 21:18:05
|
2011/8/5 Eduardo Morras <ne...@re...>: > > Hi, again more questions about the engine. > > a) What type 3D can the engine do? I mean, some engines are very good > for inner scenes (like quake, unreal, cube2..) while others are very > good for outer (palomino, openscenegraph, any flight simulator) but > performs worse or not so good in the other. May I say that this > engine is not biased to one of those types? The outer type is what > i'm looking for. It's not biased, I hope. There are optimizations that work for both scene types (frustum culling is used automatically, hardware occlusion query can be turned on --- see http://vrmlengine.sourceforge.net/news.php?id=2009-05-05 ). There are tools to improve speed specifically on outdoor scenes (we support LOD and Billboard nodes from VRML/X3D --- see http://vrmlengine.sourceforge.net/vrml_implementation_navigation.php, also fog culling may be activated --- see one of engine examples). The old "castle" game used both outdoor and indoor scenes. > > b) Networking, Which library do you use? Synapse, Freepascal "naked" net, Indy? > None, unfortunately. The engine doesn't have any built-in networking capabilities, *for now*. You can add them yourself, since FPC/Lazarus have many networing libraries (to the ones you mention, I can also add LNet). And when you do this, you can even contribute it back to the engine :) Michalis |
From: Eduardo M. <ne...@re...> - 2011-08-05 14:21:50
|
Hi, again more questions about the engine. a) What type 3D can the engine do? I mean, some engines are very good for inner scenes (like quake, unreal, cube2..) while others are very good for outer (palomino, openscenegraph, any flight simulator) but performs worse or not so good in the other. May I say that this engine is not biased to one of those types? The outer type is what i'm looking for. b) Networking, Which library do you use? Synapse, Freepascal "naked" net, Indy? Thanks in advance. Again. |
From: Michalis K. <mic...@gm...> - 2011-08-04 13:04:45
|
2011/8/4 Eduardo Morras <ne...@re...>: > > Hi, i'm new to this maillist and to vrmlengine. > > One thing i can't find in documentation is which opengl version uses. > OpenGL 2.x? 1.2? 3.x? 4.x? Hi! 1.2 is minimum. Of course, you will miss a lot of features if you only have pure 1.2 with no extensions, but it should work. For anything above OpenGL 1.2 (we want GLSL, cube maps, fbo, multi-texturing, vbo, many more), we check if OpenGL version is >= required or we use extensions. Many features up to OpenGL 2.1 are used. We do not, yet, use OpenGL 3 or 4. Although we try to avoid using features deprecated since OpenGL 3, so a migration one day to OpenGL 3 forward-compatible context is possible. Ability to use OpenGL ES (both 1 and 2) is also at hand, just waits for a developer interested in it. > > How many polys can it draw? As many as your GPU can handle... Theoretical limit in my engine is max(signed 32-bit int) ~= 2 * 10^9. But in practice your GPU will give up much earlier. I was successfully rendering some tree models with milions of triangles. Remember to turn collision off, to not waste time on building collision structures for complicated shapes (you can also use simplified "proxy" shape for collisions). > Is it a fast engine? Well, yeah :) We use modern approach to pass geometry data to GPU (everything is passed through OpenGL VBO, no display lists etc.). You're welcome to try it yourself, you can just get view3dscene and throw on it some large models. Michalis |
From: Eduardo M. <ne...@re...> - 2011-08-04 12:09:45
|
Hi, i'm new to this maillist and to vrmlengine. One thing i can't find in documentation is which opengl version uses. OpenGL 2.x? 1.2? 3.x? 4.x? How many polys can it draw? -> Is it a fast engine? Thanks in advance |
From: Michalis K. <mic...@gm...> - 2010-08-27 17:57:18
|
van Schelve, Jens wrote: > view3dscene: Exception einvalidargument : > Invalid argument Fixed. Due to floating point errors, a cosinus value calculated in one routine was very very slightly > 1 (1.0000001192092896). This made the following ArcCos(1.0000001192092896) call fail with "Invalid argument". Many thanks for providing a simple testcase, this made fixing this bug quite straightforward :) It's added to kambi_vrml_test_suite as x3d/orientation_cos_1.x3d. Until the next view3dscene release, you can use the view3dscene binary from "nightly builds" (http://michalis.ii.uni.wroc.pl/vrmlengine-snapshots/ ), to have the fixed version. Thanks, Michalis |
From: van S. J. <Jen...@ss...> - 2010-08-27 09:59:50
|
Hi Folks, I have found a strange problem while using view3dscene 3.6.0. In some rare cases while using the OrientationInterpolator the program crashes (both under Linux and Windows) with following error message: view3dscene: Exception einvalidargument : Invalid argument Here are two examples. In the first view3dscene crashes, the second works fine. NOTE that the only difference is that I canged the first keyValue z-Axis from -0.08672 to -0.08675. CRASHES: <?xml version="1.0" encoding="UTF-8"?> <X3D profile='Immersive' version='3.2'> <Scene> <TimeSensor DEF='TIME' cycleInterval='3' loop='true'/> <OrientationInterpolator DEF='ORIENTATION' key = ' 0.0 1.0' keyValue = ' -1.42800 0.00000 -0.08672 2.34200 -1.42800 0.00000 -0.08700 2.34200'/> <Transform DEF='ORIENT'> <Shape> <Box/> </Shape> </Transform> <ROUTE fromField='fraction_changed' fromNode='TIME' toField='set_fraction' toNode='ORIENTATION'/> <ROUTE fromField='value_changed' fromNode='ORIENTATION' toField='set_rotation' toNode='ORIENT'/> </Scene> </X3D> WORKS: <?xml version="1.0" encoding="UTF-8"?> <X3D profile='Immersive' version='3.2'> <Scene> <TimeSensor DEF='TIME' cycleInterval='3' loop='true'/> <OrientationInterpolator DEF='ORIENTATION' key = ' 0.0 1.0' keyValue = ' -1.42800 0.00000 -0.08675 2.34200 -1.42800 0.00000 -0.08700 2.34200'/> <Transform DEF='ORIENT'> <Shape> <Box/> </Shape> </Transform> <ROUTE fromField='fraction_changed' fromNode='TIME' toField='set_fraction' toNode='ORIENTATION'/> <ROUTE fromField='value_changed' fromNode='ORIENTATION' toField='set_rotation' toNode='ORIENT'/> </Scene> </X3D> Otherwise I am very happy with this great program. Keep working on it! Greetings, Jens van Schelve Jens van Schelve | | SSB Wind Systems GmbH & Co. KG Emerson Industrial Automation | Neuenkirchener Str. 13 | 48499 Salzbergen | Deutschland T +49 5976 946 2867 | F +49 5976 946 210 | M Jen...@ss... | www.ssbwindsystems.de Handelsregister | Commercial Register: Amtsgericht Osnabrueck HRA 100080 Geschaeftsfuehrer | Managing Directors: Dr. Gisbert Schulze, Dipl.-Betriebswirt (FH) Dirk Hamenstaedt phG | General Partner: SSB-Antriebstechnik Verwaltungs- und Beteiligungsgesellschaft mbH | Neuenkirchener Str. 13 | 48499 Salzbergen Handelsregister | Commercial Register: Amtsgericht Osnabrueck HRB 100015 |
From: Michalis K. <mic...@gm...> - 2009-03-25 05:05:08
|
Shawn Hunt wrote: > Hi, > > I am trying to modify the View3DScene code to add a new menu pic that > allows me to move the camera position around for a set interval and take > a screen shot along the way, like a controlled walking movement. I want > to be able to automatically collect data from various VRML models and > use them for analysis later. > > I created a new procedure "GenerateScreenshots" and in it I have the > increment CameraPos[0], [1], and [2] and then I am trying to do: > > SceneAnimation.Scenes[0].ViewerChanged(CameraPos, CameraDir, CameraUp); > Glw.EventResize; > Glw.PostRedisplay; > > thinking that it would change the camera's position but it isn't. I am > getting the screenshots but the camera doesn't move. Am I mssing a call > to a procedure that updates the screen? > > I'm sorry to ask but I have been fiddling around with this for a while > now and I didn't see any examples that showed me how to do this. > 1. ViewerChanged let's the Scene know the new camera configuration, but it doesn't change the actual camera settings known by view3dscene. If you want to set camera position to something computed by the code, you should rather call SetViewpointCore(CameraPos, CameraDir, CameraUp, GravityUp); This will update the Navigator positions, also making an automatic call to ...Scene[0].ViewerChanged. So you don't call ViewerChanged directly. 2. Also, to force redrawing, note that Glw.PostRedisplay may be not enough. PostRedisplay just schedules redraw at the next loop. To actually force the redraw to happen, you can follow Glw.PostRedisplay call with Glw.FlushRedisplay. Or even call Draw(Glw) + glFlush directly, that's how it's implemented in MakeAllScreenShots function (this allows to draw images to the back buffer, without wasting time on flashing them on the screen). 3. Also, Glw.EventResize call should not be needed if your projection doesn't change. So what you want in the end is something like for each camera position do begin SetViewpointCore(CameraPos, CameraDir, CameraUp, GravityUp); Draw(Glw); glFlush(); SaveScreen_NoFlush(filename for this frame, GL_BACK); end; Didn't actually test it, but should work. Unless you *want* to see the captured images, in which case you rather want for each camera position do begin SetViewpointCore(CameraPos, CameraDir, CameraUp, GravityUp); Glw.PostRedisplay; Glw.SaveScreen(filename for this frame); end; 4. Note that what you want is actually possible without modifying view3dscene source code: you can move your camera around the scene by animating your viewpoint (PositionInterpolator changing Viewpoint.position), and catch a series of images by view3dscene filename.wrl --screenshot-range TIME-BEGIN TIME-STEP FRAMES-COUNT "%d.png" Details how --screenshot-range are on http://vrmlengine.sourceforge.net/view3dscene.php#section_screenshot Actually, that's what MakeAllScreenShots function in view3dscene source code implements. Unless you have good reason to compute camera positions in source code (as opposed to designing VRML PositionInterpolator that animates the camera), using --screenshot-range may be simpler. Michalis |
From: Shawn H. <sha...@gm...> - 2009-03-20 00:45:51
|
Hi, I am trying to modify the View3DScene code to add a new menu pic that allows me to move the camera position around for a set interval and take a screen shot along the way, like a controlled walking movement. I want to be able to automatically collect data from various VRML models and use them for analysis later. I created a new procedure "GenerateScreenshots" and in it I have the increment CameraPos[0], [1], and [2] and then I am trying to do: SceneAnimation.Scenes[0].ViewerChanged(CameraPos, CameraDir, CameraUp); Glw.EventResize; Glw.PostRedisplay; thinking that it would change the camera's position but it isn't. I am getting the screenshots but the camera doesn't move. Am I mssing a call to a procedure that updates the screen? I'm sorry to ask but I have been fiddling around with this for a while now and I didn't see any examples that showed me how to do this. Thank you, Shawn |
From: Michalis K. <mic...@gm...> - 2009-01-24 04:27:52
|
I wrote: [...] >> when gravity is on and you are outside of the bounding box, strange things >> happen. > > Gravity simply stops working outside of bounding box. Yes, this is > strange, but deliberate: typically, you would fall forever, into > -infinity, if you leave the bounding box. Rather confusing for users... > view3dscene is a general 3d browser, not a game, so I cannot just kill > the player as he falls down :) That's why there has to be a limit where > gravity just stops working. > > Hm, thinking about this, it would be probably more sensible to limit > gravity to some minimal plane, instead of limiting it to bbox. I'll see, > that's some idea for tomorrow. > Done. So gravity now works outside of the box (literally :) ). This will hopefully make it more sensible. Michalis |
From: Michalis K. <mic...@gm...> - 2009-01-20 03:36:33
|
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 think you meant when gravity is on, Ah yes. > > when gravity is on and you are outside of the bounding box, strange things > happen. Gravity simply stops working outside of bounding box. Yes, this is strange, but deliberate: typically, you would fall forever, into -infinity, if you leave the bounding box. Rather confusing for users... view3dscene is a general 3d browser, not a game, so I cannot just kill the player as he falls down :) That's why there has to be a limit where gravity just stops working. Hm, thinking about this, it would be probably more sensible to limit gravity to some minimal plane, instead of limiting it to bbox. I'll see, that's some idea for tomorrow. Michalis |
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 |
From: <da...@la...> - 2009-01-20 02:51:52
|
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 think you meant when gravity is on, when gravity is on and you are outside of the bounding box, strange things happen. David Lang > 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 > > ------------------------------------------------------------------------------ > 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-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 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: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:37:49
|
da...@la... wrote: > On Tue, 20 Jan 2009, Michalis Kamburelis wrote: > >> da...@la... wrote: >>> as I'm working with view3dscene I am finding that some of the doorways do >>> not fully penetrate the walls. can you tell if there is an error in the >>> 3ds file or if it's in the conversion? >>> >> All I know about 3ds is basically what my engine can display... How >> *should* it look like, i.e. what do you mean by doorways not penetrating >> walls? Which format in http://vrml.lang.hm/vrml/ is the source file? >> >> I compared kadota-land.3ds and kadota.3ds viewed by view3dscene with >> what is shown after importing these 3ds into blender, resulting geometry >> is pretty identical, so on the 1st look I see no errors in view3dscene >> 3ds handling. > > around the 'back' of the house there are two sets of stairs. there is a > door at the top of each of the stiars, but that door doesn't go all the > way through the wall. for one door you can see it from the outside, but > not the inside, for the other you can see it from the inside, but not the > outside. > Ah I see them (the ones on the attached screenshot?). Blender importer shows the same geometry for them, with the same problem --- so it looks like this is what is stored is 3ds file. > hmm, I'll consider it, but that would trip me up when I work on the model > with other tools and external objects. That's why the "Inline" trick could be helpful, as then your 3ds data stays separate from VRML things. Oh, and I of course forgot to attach the sample VRML file that shows this inline --- attaching now. Michalis |
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: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:13:14
|
On Tue, 20 Jan 2009, Michalis Kamburelis wrote: > da...@la... wrote: >> as I'm working with view3dscene I am finding that some of the doorways do >> not fully penetrate the walls. can you tell if there is an error in the >> 3ds file or if it's in the conversion? >> > > All I know about 3ds is basically what my engine can display... How > *should* it look like, i.e. what do you mean by doorways not penetrating > walls? Which format in http://vrml.lang.hm/vrml/ is the source file? > > I compared kadota-land.3ds and kadota.3ds viewed by view3dscene with > what is shown after importing these 3ds into blender, resulting geometry > is pretty identical, so on the 1st look I see no errors in view3dscene > 3ds handling. around the 'back' of the house there are two sets of stairs. there is a door at the top of each of the stiars, but that door doesn't go all the way through the wall. for one door you can see it from the outside, but not the inside, for the other you can see it from the inside, but not the outside. David Lang |
From: Michalis K. <mic...@gm...> - 2009-01-20 00:37:49
|
da...@la... wrote: > as I'm working with view3dscene I am finding that some of the doorways do > not fully penetrate the walls. can you tell if there is an error in the > 3ds file or if it's in the conversion? > All I know about 3ds is basically what my engine can display... How *should* it look like, i.e. what do you mean by doorways not penetrating walls? Which format in http://vrml.lang.hm/vrml/ is the source file? I compared kadota-land.3ds and kadota.3ds viewed by view3dscene with what is shown after importing these 3ds into blender, resulting geometry is pretty identical, so on the 1st look I see no errors in view3dscene 3ds handling. Michalis |
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-19 22:34:43
|
as I'm working with view3dscene I am finding that some of the doorways do not fully penetrate the walls. can you tell if there is an error in the 3ds file or if it's in the conversion? David Lang |
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-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 |