Billiards

[Post a new comment]
Comments

	Very nice posted by Moja @ 72.48.89.48 on Mar 19 2009 3:50 AM
In Fedora Core 10, I wasn't really sure what to override the LUA_CFLAGS and/or LUA_LIBS with using configure, so I ended up editing the configure script directly (I know, I know) and replaced all (10) instances of "lua5.1" with just "lua". Then I had to do "export LUAC=/usr/bin/luac". After that it built/installed fine. Well, that is after rebuilding ode. For other FC10 users, its really not that difficult. You can get the source RPM of ode here Make sure you have the rpm-build package installed ("rpm -q rpm-build") If you do not, then install it (as root, "yum install rpm-build") Then download the source RPM from one of the mirrors above and install ("rpm -Uvh ode-0.10.1-1.fc10.src.rpm") Then edit the spec file (should be ~/rpmbuild/SPECS/ode.spec) Find this line: "%configure --enable-shared --disable-static" Change it to the line below and save it: "%configure --enable-shared --disable-static --disable-asserts --with-trimesh=opcode --enable-double-precision" Then rebuild the RPMs ("rpmbuild -bb ode.spec") Look in ~/rpmbuild/RPMS/i386 for the shiny new RPMs Install using "rpm -Uvh ode-0.10.1-1.fc10.i386.rpm ode-devel-0.10.1-1.fc10.i386.rpm" If they are already installed, you can do (as root again) "rpm -e ode ode-devel" prior to the above command to uninstall, or use the "--force" command-line switch to override the existing ones. Now recompile/reinstall billiards, and it should work great. Good luck!
[Reply]
Re: Very nice posted by dpapavas @ 79.167.120.18 on Mar 21 2009 10:06 AM   Thanks for posting these instructions! I suppose I should build Lua and ODE into the distribution and link them statically as this would save a lot of people a lot of hassle but I don't really like the idea. Maybe I should provide some preconfigured source distributions and some sort of configure option to use those. I'll try to look into it when I get some time. The truth is I was hoping for the package maintainers of the various distros to fix this issue for me. :)   [Reply]

	Awesome!! posted by bobsmith @ 91.23.10.177 on Mar 11 2009 5:50 PM
I'm giving 5 stars, even though theres still a ways to go before it's really ready for use. Just a note. It doesn't seem to work with any version of ODE past 0.9. I have it running full featured. The web interface is a really cool idea. You can actually see the weave of the playing surface (what is that simonis 860 ?;)) This is the first pool game that I have played on a pc since virtual pool that actually has the right feel. The physics from ODE are nice ! Things still needed : Jump ball... the ability to position your view when lining up a shot. It can be done but it moves so slow. Sound. Awesome job! you have a fan :)
[Reply]
Re: Awesome!! posted by bobsmith @ 91.23.10.177 on Mar 11 2009 5:56 PM Whoops... spoke too soon about the jump :) 5 more stars ;)   [Reply]   Re: Awesome!! posted by dpapavas @ 79.167.108.239 on Mar 13 2009 8:09 PM   Balls can jump out of the table due to spin when hitting other balls or the rails but you can't perform a jump shot, that's true I'm afraid. The problem is that I'm not sure whether jumpshots can be modelled with a rigid body simulator without faking them (because I suspect they depend on the cue flexing during contact with the ball) and I don't want to fake them (mostly because that would require experimental data which I don't have to get it right.) Now as for adjusting your view while aiming, the action is deliberately so slow. The idea is that you more or less line up the shot while looking around and once you set up your cue and start aiming you'll only want to fine-tune. It takes some getting used to I suppose. That being said you can configure the sensitivity when looking around zooming or stroking using variables inside ~/.billiards altghough I've just noticed that i haven't included those in the GUI settings page. I've done this now and also added a variable to control fine-tuning sensitivity (it was hard-coded up until now). The changes have been checked into CVS and will be included in the next release. Sound is actually supported code-wise but I'll have to somehow get my hands on decent royalty-free samples. If someone out there has access to a pool table and a good microphone let me know.   [Reply]   Re: Awesome!! posted by bobsmith @ 91.23.27.132 on Mar 14 2009 12:18 PM I don't think jump shots require flex in the cue. Most jump cues people use these days are part of their break cue, which usually has a thicker more rigid shaft. The key is the tip of the cue. Most jump/break cues have a tip that is hard as hell. The jump shot works by shooting the ball into the table. Depending on the elevation of your cue and the contact with the cue ball, the ball will jump, or masse. What do you need as far as sound it concerned ? I would think you need maybe 5 different sounds : ball to ball, cue to ball(good hit, and miscue), ball to rail, ball to pocket. The intensity of the sound would then depend on the physics involved...   [Reply]   Re: Awesome!! posted by dpapavas @ 79.167.120.18 on Mar 21 2009 9:54 AM   It's not that the cue is required to be more flexible but I suspect that the problem is that ODE, being a rigid body simulator, considers the collision to be instantaneous and that's where the problem is. Because at the instant of impact the cue is on top of the ball thus not allowing it to move upwards. But in reality the impact phenomenon takes some time during which the cue (partly due to its deformation I think) gets out of the way. If I set things up so that the cue "disappears" at the moment of impact, the ball jumps, although the jump is exaggerated. Regarding sound the nice thing is that spheres, being perfectly symmetric, sound the same no matter how they're struck, except for the volume of course. But still to avoid regularity it would be nice to have two or three samples of each sound (that is, ball-to-ball, ball-to-cushion, ball-to-table, ball-to-cue) and then there's the rolling of balls inside the table before ending up in the collector. By the way, there's a mailing list on the project home page which would be more suitable for this kind of discussion (that goes for all threads of course). it's also currently quite empty causing me some embarassment... :)   [Reply]   Re: Awesome!! posted by James Gregory @ 213.107.75.169 on May 5 2009 10:07 PM   Isn't it the table which flexes rather than the cue? A jump shot on a rubber table would be easy, a jump shot on a marble table very difficult.   [Reply]   Re: Awesome!! posted by bobsmith @ 82.141.45.121 on May 6 2009 12:09 PM The table does not flex... it most cases it is a 2.5cm sheet of granite. In a jump shot, the cue ball jumps simply because that is the only way it can go. The cue basically pinches the ball with the table. First, picture what you do with a draw shot... you hit low on the cue ball. When you jump, your view of where the cue hits the cue ball should be relatively the same, except for the fact that the angle of your cue over the table is bigger. The physics engine, calculating on "instant of contact" shouldn't be the problem. In the real world, it has been measured, that the time a cue tip is in contact with the cue ball is ~1/10000th of a sec... virtually instantaneous.   [Reply]

	Uuhhh... posted by Pit @ 130.237.166.167 on Jan 15 2009 2:10 PM
Anyone got this to run? I had to recompile my ODE (default package has only static libs, and I got tons of unresolved symbols), now it finally compiles (using ode 10.1) but when I start it I get ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in _dNormalize3() [../../../include/ode/odemath.h] /usr/local/games/bin/billiards: line 7: 1564 Aborted ./billiards.bin $* A pity - it looks quite promising. Pit
[Reply]
Re: Uuhhh... posted by dpapavas @ 213.249.56.36 on Jan 15 2009 3:07 PM   What distro are you running? This error message is due to the fact that a (nearly) zero-length vector is sent to the normalization function. Anyway the ode packages in debian for instance have these checks disabled so there must be some configuration option to do this (possibly --disable-asserts, I can't check this right now as I don't have access to a linux box). Also if you're running a 64bit CPU you'll want to use OPCODE for trimesh collisions as GIMPACT won't work (--with-trimesh=opcode). Let me know if it works and don't forget to try the web-based gui as well (connect to localhost:29176 after starting the game).   [Reply]   Re: Uuhhh... posted by Pit @ 130.237.166.167 on Jan 16 2009 1:53 PM   Hi! Thanks for the answer. This is an openSUSE 11.0, where I installed the latest ode myself. I tried recompiling ode with --disable-asserts, but that didn't help :( However, I found that there is an error before that I didn't realize so far: Mesa 7.0.3 implementation error: User called no-op dispatch function (an unsupported extension function?) Please report at bugzilla.freedesktop.org So it's probably me lacking a suitable graphics card? Pit   [Reply]   Re: Uuhhh... posted by farvardin @ 88.161.145.237 on Jan 16 2009 5:55 PM   I have ode0.10.1, and I could compile and install billiards on my archlinux computer. But when running it, I got: ODE INTERNAL ERROR 2: geom must be placeable in dGeomSetBody()   [Reply]   Re: Uuhhh... posted by dpapavas @ 79.167.107.249 on Jan 17 2009 11:25 AM   Pit, It seems the normalization issues where my fault after all although I can't understand why this didn't come up with the debian packaged version of ODE. Anyway the fix is simple so you can either download and compile the current cvs version or, because then you'll need to use autoconf and automake to create the configuration script and makefiles which are not provided with the cvs version, you also have the option of making the necessary changes yourself for now. Just do: grep Normalize *.c inside src and change all instances of dNormalize3 to dSafeNormalize3. That should take care of the asserts. You'll also have to compile ODE like this: ./configure --enable-shared --enable-release --disable-asserts --with-trimesh=opcode to get rid of the INTERNAL ERROR messages farvardin mentions below. This gets Billiards to run with ODE 0.10.1 for me but it behaves pretty strangely. The cue goes through the cueball and you can't move the balls around. Can you confirm that you get the same behavior as well. I find it a little weird as according to the Changelog version 0.10.1 doesn't have important differences with respect to 0.10 which I am using right now. Also regarding your graphics card issues: the truth is I haven't had a chance to run Billiards on many graphics cards. If you have an GeForce you should be able to run it with full shading. If you have an Radeon (or any ATI card) the boot script will currently automatically switch to simple toon shading. This may not be a good idea but the simple integrated Radeons I have tried couldn't handle full shading. Anyway if you have trouble running Billiards due to your graphics card try running it like this: billiards -Otoon otherwise if you can run it but it defaults to toon shading and you want to try the full shading codepath try this: billiards -Onotoon In any case let me know how it goes. I'm particularly interested in how billiards runs on different hardware. PS: I'll make a new release with the necessary changes as soon as all this is sorted out.   [Reply]   Re: Uuhhh... posted by Pit @ 80.216.110.99 on Jan 17 2009 8:34 PM   Thanks for your guidelines. Indeed it starts up now. However, indeed my graphics card is way to weak for this (It's my laptop, the gaming machine is at home which is some 5000km away due to some work related travel...). So I'll come back to billiards once I'm at the real machine and hope my comments were nevertheless useful ;^> Pit   [Reply]   Re: Uuhhh... posted by dpapavas @ 79.167.107.249 on Jan 18 2009 12:59 AM   I doubt your graphics card is too weak for toon shading mode. This might be yet another problem I'm trying to solve. In the opening position in the game of pool the balls are close together so that too many contacts exist at the same time slowing the game down. To check whether this is true start it like this: billiards -Otoon -Ocarom this will start a carom game where the situation is much better. If it runs ok then let me know and I'll send you a patch to try out. By the way, what graphics card do you have? Can you run it in full shading mode? farvardin, have you had any luck running it?   [Reply]   Re: Uuhhh... posted by farvardin @ 88.161.145.237 on Jan 18 2009 10:29 PM   yes, it's running now after modifing the source and recompiling ODE. But I'm afraid it's still very slow. Running your command line arguments (-Otoon -Ocarom ) made the game faster indeed. It looks awesome, but I still don't know how to strike a ball. I'll search the manual tomorrow :)   [Reply]   Re: Uuhhh... posted by dpapavas @ 213.249.56.36 on Jan 19 2009 9:38 AM   Uhhh, the manual you say... That's sort of outdated to say the truth. A sad consequence of lack of time caused by wage slavery. Anyway you should read it but provided that the game runs correctly (as I've said I coudn't get it to behave well with ODE 0.10.1) you only need the mouse to play it. Just click and drag with each mouse button on the cue, balls and rest of the screen and you'll figure it out. There's nothing much to it. Don't forget to use the webgui though. What sort of graphics card do you have though? I think that if you can actually run the game in full shading, you should be able to get a more or less decent framerate as well. Try to run in full shading carom mode like this: billiards -Ocarom -Obilliards -Oframerate If that's better then the problem lies elsewhere and hopefully I'll have a patch soon.   [Reply]   Re: Uuhhh... posted by farvardin @ 88.161.145.237 on Jan 20 2009 12:29 PM   yes that's much better with this new options ! But the framerate is not that good, I have 15-17 fps while on the same computer with World of Warcraft (using Wine), I get 20-22 fps on more complicated scenes. My card is a NVIDIA integrated card, ref. GeForce 6100, using the nvidia drivers. About the game, I could select balls and have several options for playing, but couldn't strike them.   [Reply]   Re: Uuhhh... posted by dpapavas @ 213.249.56.36 on Jan 20 2009 3:04 PM   Yes, well Billiards is not particularly optimized as it, or rather the platform it's running on, is work in progress (and will remain so for a long time probably). Also Billiards is very physically intensive (the default timestep is as low as 0.001s) and it uses fancy shaders for most surfaces as well (the cloth, metal panels, etc). That said it would make sense to include some options to switch quality based on your computer but I thought that, given that I could get a decent framerate on my relatively cheap laptop this wouldn't be necessary(don't quite remember the GPU now but it gets me 40-50fps with 4x FSAA and then there's always simple toon shading). I'll look into the matter once the more critical problems have been resolved. You might want to fiddle with the options in the webgui or in ~/.billiards to see if you can get it to speed up a little. Now speaking of more critical problems, I'll have to look into resolving this issue with ODE 0.10.1 but this will probably take a few days due to the aforementioned wage slavery issue. In the meantime you could try to build against a previous ODE version. In fact it would be probably best to use the source that was used to build the debian package I'm using (but without the changes made by the Debian maintainer). You can get this here: http://ftp.de.debian.org/debian/pool/main/o/ode/ode_0.9.orig.tar.gz The latest experimental debian ODE package uses version 0.10.1 so I'll install that and try to figure out the necessary changes. Could you also post framerates with these configurations by the way: billiards -Oframerate billiards -Onineball -Oframerate That's all for now. Stay tuned and let me know how you all do with ODE 0.9 and the provided compile options. Dimitris.   [Reply]   Re: Uuhhh... posted by Pit @ 80.216.110.99 on Jan 20 2009 10:36 PM   Hi Dimitris, I compiled the 0.9 version of ode and now I'm able to hit the ball :) Looks like in toon mode there is no display of framerates? At least I couldn't see anything, neither on screen nor on the console output. Standard pool is unplayable even in toon mode - a frame update every few seconds. The nineball version is very sluggish (~2-4 fps), carom mode is fine - the CPU runs at ~95%. From that it looks like a very nice implementation of the game physics. As I said, it's only my (very old) laptop with Intel 855GM. Looking forward to test it on a better hardware :)   Pit   [Reply]   Re: Uuhhh... posted by dpapavas @ 213.249.56.36 on Jan 21 2009 8:52 AM   So you mean to tell me that you're able to get full shading to work with an intel 855GM? I'm very impressed! The main reason I implemented toon mode was to allow the game to run on simpler hardware like that but it seems the situation is much better than expected (except with ATI drivers of course but one can always hope). Does carom run fine in full shading? Do the graphics look like the screenshots or are there artifacts of some kind? If you get better framerates as ball count decreases the slowdown might be caused by physics, not graphics. Try changing the simulation stepsize and tolerance. The current stepsize is 0.001 and is probably too low (I set it as low as I could get it to run on my setup) and you might want to raise it to say 0.005 or even 0.01. The change can be made through the webgui under the dynamics section in settings. The parameter is 'stepsize'. Also change the solver tolerance which is parameter 'softness' in the same section. The current value (1e-7 or a tenth of a micrometer) might be ridiculously low. Try setting it to 1e-6 or something like that. Maybe even higher. Experiment, and let me know how the new settings work. PS: No framerates in toon mode eh? I'll look into it.   [Reply]   Re: Uuhhh... posted by Pit @ 130.237.166.167 on Jan 21 2009 2:17 PM   Dimitri, Sorry if I was unclear - no, no way to run other than toon mode. The fps I gave were estimated from the jumping image when (trying to) rotate the FOV. When I try to run with -Onotoon, the game segfaults (billiards: line 7: 9420 Segmentation fault). Probably this is related to the Mesa error message I mentione earlier? (This error is continuously reported in the console where I started the game is running). Or is it just too little memory? Ha, the web interface is fun ;^> Guess I can also change things in the config file.... Increasing time step slightly reduced CPU load, but still not enough to play nineball. With carom I get some 40% CPU both from billards and the X server. Pit   [Reply]   Re: Uuhhh... posted by farvardin @ 88.161.145.237 on Jan 21 2009 12:27 PM   it's working with ODE 0.9, I understand now why I couldn't strike the balls (bug with ODE 0.10). I can only play it with the -Ocarom option, otherwise it's much too slow. Looks like it could be a great game!   [Reply]   Re: Uuhhh... posted by dpapavas @ 213.249.56.36 on Jan 22 2009 8:17 AM   The segmentation fault is probably caused somewhere inside the driver during shader compilation or execution. Regarding the slow performance with pool games though, they may be caused either by way too resource-hungry simulator configuration, or by the way the balls are set up for the break shot. If the framerate permits, try to make a break to see whether that's the problem. I haven't had a chance to even boot my home computer during these past days but when that happens (today hopefully) I'll send you patches and simulator parameter suggestions to try out.   [Reply]   Re: Uuhhh... posted by farvardin @ 88.161.145.237 on Mar 9 2009 10:41 PM   I tried to compile the new version with " --enable-shared --enable-release --disable-asserts --with-trimesh=opcode", but I'm still getting the "ODE INTERNAL ERROR 2: geom must be placeable in dGeomSetBody() /usr/bin/billiards: line 7: 28277 Abandon ./billiards.bin $*" and the game crashes.   [Reply]   Re: Uuhhh... posted by dpapavas @ 79.167.108.239 on Mar 13 2009 8:19 PM   Um, just to be sure, you pass those switches when configuring ODE right? If so, then this is how I configure ODE 0.10.1 and it works fine for me: ./configure --enable-shared --disable-asserts --with-trimesh=opcode --enable-double-precision You'll need double precision or you'll get funny instabilities otherwise. Also make sure you 'make uninstall' the previous version before running 'make install' on the new one and that you reconfigure and remake Billiards itself after recompiling ODE. You can also make sure that billiards uses the correct ODE version by looking at the messages output by ./configure: checking for ode-config... -I/usr/local/include -DdDOUBLE checking for ode-config... -L/usr/local/lib -lode These should point to the place where you installed ODE. ODE 0.11 also works but they seem to have reversed something in the slider joint so the cue now moves back instead of forth and vice-versa. Let me know if you can't get it to work.   [Reply]