Re: [Soya-user] compiling soya from svn or 0.15
deavid wrote: Tarballs should have a root folder named "packagename-packageversion", where packageversion comes in X.Y.Z format. Yes, but I don't see why it can't have a 'soya' subdirectory under the soya-X.Y.Z root directory. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] compiling soya from svn or 0.15
deavid wrote: Soya source tarballs have a root folder named "soya-x.y.z". This makes soya not buildable with pyrex or cython. So why doesn't the source tarball come with the necessary subdirectory in the first place? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Soya basic help
Jiba wrote: I think you should (try to) use Cython instead of Pyrex ; it is the new way of compiling Soya and usually works better (I have some weird bugs with Pyrex on some specific functions). Can you tell me about them? If there's something that Pyrex is doing wrong, I'd like to fix it. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] CoordSyst matrix
Fabio Varesano wrote: does anyone knows what's inside _matrix of CoordSyst? It's a 19 elements matrix. It's a while since I delved into it, but as far as I remember it's a standard 4x4 transformation matrix plus three precomputed scale factors. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] rotating objects from an accelerometer output: python + pyserial + soya 3D + Arduino + ADXL330
Fabio Varesano wrote: > However, I'm stuck on how to rotate my cuboid according to the angles > calculated from the accelerometer. If I use the code posted above the > animation become really slow and sloppy till almost not working. If I understand your code correctly, you're reading one sample from the accelerometer for each animation round. But if the accelerometer is producing data faster than the frame rate of your animation, this isn't going to work. For example, if your animation is running at 60fps and the accelerometer is producing 300 readings/sec (as you indicated in one of your posts), then your animation is only using accelerometer data at one-fifth of the rate needed to keep up, so it will lag further and further behind. What you need to do is, for each frame, take all the accelerometer data that has come in since the last frame, accumulate all their rotations and apply them to the model, before rendering the frame. You may want to use a separate thread to read the accelerometer samples and put them in a queue for the animation thread to process. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Patches to Soya3D that allow compiling with latest Pyrex
deavid wrote: > ODE collisions work, when using single precision libraries of ODE. > > But it fails in the following tutorials: I don't know whether it's related to your problem, but I've found that trouble can arise if you're not using the same version of ODE that the code is expecting. Annoyingly, ODE always installs itself under the same name by default, despite there being important differences between versions. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] GL_POINT_SMOOTH
snaipperi wrote: > I'm trying to soya.opengl.glEnable(soya.opengl.GL_POINT_SMOOTH) to > gain smooth points, but they still appear as squares. Is this a > hardware problem or a feature not implemented (soya 0.13). I discovered in a non-Soya project once that you have to turn on blending with glEnable(GL_BLEND) in order for round points to work. Maybe Soya isn't doing this? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] External scene manager project, ask for opinion
Souvarine wrote: > I have been told that SketchUp is the only modeler that support > collada natively and properly (don't know if that is true). Even if it is, it's probably only in the version you have to pay for, not the free version (which comes with very few exporters). On the other hand, Sketchup is scriptable in Ruby, so you can probably program it to export in just about any desired format, given enough work. I think there's also a C++ library you can call from external code to read Sketchup files, if you want to approach the problem from the other end. Being able to create scenes for this thing in Sketchup is something I'd be very interested in! > Since you > like SketchUp, can you tell me if it is possible to model a whole level > with it ? Including the possibility to model terrains, put light > sources, place locations and name them, label some parts of the geometry > with specific names ? I've recently been working on a project using Sketchup to create levels for Aleph One (an open source development of the Marathon game engine). I managed to get it to do very nearly everything the Marathon engine supports, all with Ruby scripting inside Sketchup. Ruby code can attach arbitrary attributes to any object in the model, so there should be no trouble naming things. Light sources and such like can be modelled using placeholder objects that are recognised and treated specially by the exporter. There is a set of "sandbox" tools that could be used to edit a terrain mesh. So yes, all those things should be doable with Sketchup, I think. Something to consider when deciding on an export/import strategy is that funneling everything through a common format can lead to loss of information. Some modellers may support things that it would be useful to get into the scene for the game engine to use, but if they can't be expressed in the intermediate file format, you're out of luck. For example, Sketchup has a very powerful notion of component definitions and instances, which can greatly reduce the amount of data needed to describe a scene with a lot of repeated elements. But if the intermediate format didn't support component instances, the game engine wouldn't be able to take advantage of that. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] External scene manager project, ask for opinion
Souvarine wrote: > I'm planing to start writing an > independent scene management library that would not be tied to any 3D > engine, and would be potentially be used by any existing 3D engine, > including soya of course. This sounds very interesting, especially the part about being able to use a variety of existing 3D model formats as input. I'll be looking forward to seeing what you come up with! -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Fw: about Soya 3D
Ilja Krjuchkov <[EMAIL PROTECTED]> wrote: > I am have some truble with Soya,please help me:) > I am tray to install Soya-0.13 > and have error : > > /Users/iljakrjuchkov/Soya-0.13/model/terrain.pyx:1464:70: Cannot > assign type 'float' to 'int' This looks like the sort of problem you get when you have a different version of Pyrex installed than the one that was used by Jiba last time he made a Soya release. If you're only trying to install Soya, and not trying to compile modified Pyrex sources, the best thing to do is modify setup.py so that it doesn't use Pyrex, and just uses the .c files included in the distribution. To Jiba: I strongly recommend that you don't distribute with a setup.py that uses Pyrex by default, even if it's installed on the user's system. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Julian Oliver wrote: > linking against GPL'd code doesn't magically force your code under the > GPL. linking against it and then distributing that linked code does. The point is that if you link your program with GPL code, the GPL's restrictions concerning distribution come into effect for the rest of your code. If you don't intend to distribute your code, then restrictions against distributing it obviously are of no consequence for you. But that doesn't mean that the restrictions are not there. > here's a good clarification on the topic: > > http://www.groklaw.net/article.php?story=20031214210634851 Hmmm, I think we've been misunderstanding each other. When I say that the GPL is "viral", I don't mean it in the mistaken way that this article is trying to clear up. I only mean that its restrictions spread further than just the code originally licenced under the GPL. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > Strictly speaking, you could probably just ignore the EULA and use the > product without accepting the license, because then it would fall back > to the copyright law that doesn't restrict use, only distribution. > That's probably why they are made as "click-wrap" - to ensure you cannot > do it. Even click-wrap doesn't prove anything. Who's to say I didn't leave the room and let my cat walk on the keyboard until it accidentally hit the Accept button? :-) -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > if it weren't GPL (or other license granting you > the freedoms), you wouldn't have any rights to copy/distribute the > software under the copyright law. I mean that you can use one of the other open-source licences that don't have any viral clauses in them. > This is very different from e.g. Microsoft's EULAs, which *only* > restrict even the remaining rights you would have under the copyright > law and do not grant you any additional freedoms whatsoever. I've never been entirely sure what gives them the right to make such restrictions. Copyright law says you need permission to copy something, but it doesn't say you need permission to *use* it. I suppose they would argue that in order to use it you have to copy it onto your computer's disk. But that's like saying I need a licence to read a book because I'm copying it into my brain, or something. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > Yes, but you first need to HAVE the documentation! Why do you think the > DRM and NDAs and all this is in place to begin with??? Try to ask Sony > for development documentation - they will either politely show you the > door or laugh in your face directly. My point is that all this comes under the "necessary information" clause, IMO. If they are using modified GPL3'ed code in it anywhere, they *have* to provide all of that -- otherwise you're missing information needed to install your own modified version based on their source. > Do you think that the reason why there is no such toolchain > is the DRM and proprietary disk format? I think that if it were feasible to run the result on a standard, unmodified Playstation, there would be a lot more incentive for someone to come up with such a toolchain. I'm sure there are many enterprising young hackers -- er, enthusiasts -- around who would relish the challenge. > However, if you had only a standard > license, the work could just disappear - e.g. you obtain the copyright, > get the source under your control and then change license to a > proprietary one and yank the project off the web. If the original copyright holder doesn't want this to happen, all he needs to do is not relinquish the copyright to anyone. I don't see the need for a viral licence to protect against this. For further reassurance, a non-revokability clause could be included in the licence. I'm not sure whether such clauses are legally binding, but if they're not, then the GPL itself provides no more protection in this respect. > The second point of the virality is that you are *not allowed* to take > my work, enhance it with proprietary extensions and start distributing > it (selling it, for example) without making the code for those things > available. This prevents forks and splintering of the code base into > incompatible versions. Well, it might help with that, but this still comes into the category of "giving something back". If you don't care about getting anything back, you're at liberty to ignore all the proprietary versions, and you're no worse off than if they didn't exist in the first place. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Julian Oliver wrote: > there is nothing intrinsically 'viral' about the GPL - a term used to > imply that GPL licensed code aggressively infects any code-base it comes > into contact with - converting it indefinitely. But that's exactly what it does do. If you link any GPL code to your program, the whole program becomes GPL. If that's not a kind of infection, I don't know what is. It's true that a piece of GPL code won't come crashing in through your network connection and infect your code without your consent -- you have to choose to use the GPL code in the first place. But I think most people using the term "viral" w.r.t. the GPL understand that (with the possible exception of Microsoft). -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > Sorry, no. Distribution is *not* use. Distribution is fairly clearly > defined in both the license and the copyright law. I think we're getting sidetracked by choice of words here. What I mean to say is that the GPL not only says what you *can* do with the software, it also says what you *can't* do with it (i.e. modify + distribute + don't provide source). Those restrictions are mainly what distinguishes the GPL from most other open-source licences. So, the GPL-ness of the GPL is mainly about imposing restrictions, not granting freedoms. If granting freedoms is *all* you want to do, you don't need to use the GPL. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > I think that this is your problem. Try to make sense of it first, before > you advocate changes you do not understand. I have tried to make sense of it, several times. The conclusion I've come to is that RMS isn't really claiming that virality is necessary to ensure that existing versions remain free. The reasons he puts forward for the virality have to do with encouraging *more* open-source software to come into existence. Which is fine if that's what your goal really is, but it's important to be clear about it. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > You are wrong here. GPL gets triggered *only* by the act of > distribution, not by use. But distribution is a kind of use. So it does put some restrictions on some uses. > It is *not* a "gift economy" - selling > free software is perfectly OK and the whole deal is not about price Not a monetary price, no, but there is a kind of price. The currency is ideas and improvements to the software. > but > about the freedoms as defined in here: > http://www.gnu.org/philosophy/philosophy.html I don't see anything in the basic freedoms defined there that needs a *viral* licence in order to preserve it. On the other hand, under "Copyleft: Pragmatic Idealism", as motivation for using the GPL, several examples are given of improvements released as open source that wouldn't otherwise have been. So as far as I can see, the only reason to use the GPL rather than a more liberal licence is if you want to encourage *future* software to be free, not just what you're releasing at the time. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > The key is "to build and run" - GPL explicitly asks only for "install > and execute", not to build. If you know enough about the platform to be able to "install and execute", then I think you know enough to be able to write your own tool to get from the source to the executable. I can't see there being anything in the compiler itself that's tricky -- it's things like proprietary disk formats and built-in DRM chips that will trip you up. Given the same information that the manufacturers themselves have about such devices, building the necessary tools is just a matter of programming. > Actually, neither - it is about maintaining the freedom. Well, that's what RMS *says* it's about, but that's never made any sense to me. If someone takes a free program and makes something proprietary out of it, the original version is still just as free as it ever was -- you don't need a viral licence agreement to ensure that. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > Compared to v2 that tried to deal only with issues of distribution and > copying, v3 tries to go into restricting certain uses But the GPL has always been about restricting uses. If it weren't, it wouldn't be much different from any of the other, more liberal open source licences. > Who gives you the right to restrict my rights to my > hardware in such way? If I were a GPL enthusiast, I would probably answer that you have a right to restrict your hardware however you want, but not necessarily to use *my* program to help you do it. > making my HW tamper-proof ... brings me more revenue (and perhaps > it is even a legal must - e.g. medical equipment!) Tamper-proofing for reasons of safety or security is one thing. But doing it for the reasons that Sony or TiVo do, i.e. simply to lock out competitors, is kind of opposite to the whole spirit of free software, and it rubs the GPL people up the wrong way. Personally I think the whole GPL business is more trouble than it's worth, and I prefer to use much less restrictive licences for what I release. But I can understand the GPL community's point of view -- they're trying to operate a gift economy, and they see someone who only takes gifts and never gives any back as being parasitical. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > GPL v.3. does not force anyone to release the compiler and > development kit. It requires only the *installation information*, > defined as: > > “Installation Information” for a User Product means any methods, > procedures, authorization keys, or other information required to install > and execute modified versions of a covered work in that User Product > from a modified version of its Corresponding Source. Which, if they're using a compiler and other tools that are so nonstandard, seems like it *would* require them to release those tools, or at least enough information to enable someone to build their own tools to do the same job -- since this is "necessary information" to be able to build and run modified versions. > Moreover, preventing people from profiting from your code is actually > not what GPL is about No, it's about them making use of your code without giving something back. I understand that it's not about money. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] again on gpl v3 (tivoization)
Jan Ciger wrote: > This is a red herring - neither PS nor Wii are able to run code unsigned > by either Sony or Nintendo. > > Please, find a better example. Surely this is *exactly* the kind of problem being talked about? All the source code of the Playstation's OS and its games could be disclosed under the GPL, yet it wouldn't do anyone any good. Whether this matters to you depends on whether you want to prevent a company from profiting from your code in a manner like this. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] setting full 3D orientation
Jiba wrote: > You can read or write the coord syst matrix using the matrix attribute. > However, you should do it carefully... It would be good if there were an API something like obj.set_orientation(xaxis, yaxis, zaxis) which aligns and scales the object so that its local axes transform onto the specified vectors. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] setting full 3D orientation
Souvarine wrote: > You > can do that by first using the set_identity method that reset your > coordsyst position and rotation and after that rotate or turn methods. I think he already has a rotation matrix obtained from somewhere else, not a set of angles. I had the same problem when I was trying to load a model from a file created in a 3D modelling application and build a Soya data structure for it. There needs to be some call for directly setting the rotation matrix. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Building soya from svn
[EMAIL PROTECTED] wrote: > No one to explain me where ode_check.h is supposed to come from ? It was supposed to be part of a patch I sent to Jiba a while back. Seems like it either got left out of the patch or he hasn't included it in the repository. I've attached it below. Jiba, you may want to make sure it gets put in the repository. -- Greg /* * Check that ODE is configured to use floats and not doubles. * Otherwise chunk_add_float_endian_safe gets passed pointers * of the wrong type. * * Greg Ewing, March 2007 * [EMAIL PROTECTED] */ #include #ifndef dSINGLE #error Soya requires ODE to be configured with PRECISION=SINGLE #endif ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] render problem
marmoute wrote: >> I've noticed on MacOSX that some of the examples give a >> continuous spinning beachball > > on os X you have to use pythonw instead on python I know, but it doesn't help in the case of these particular examples. The examples which make use of keyboard input don't exhibit this behaviour. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] render problem
Ting Li wrote: > It seems if the graphics window is waiting for some input event, e.g. using > soya.process_event() in the > script, this problem will not appear. I think Soya does some odd things when an app is not doing the full handling of input events that would normally be done in a real application. I've noticed on MacOSX that some of the examples give a continuous spinning beachball when run from a Terminal, and instead of keyboard events going to the Soya process they go to the Terminal instead, even when it's not in the foreground. It doesn't seem to stop any of the animation or graphics from working, though. Maybe the solution is just to update those examples so that they run an event loop properly? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Another small patch for Python 2.3
Here is a small patch to blendercal to enable it to
work with Python 2.3.
--
Greg
diff -r -u blendercal-orig/__init__.py blendercal/__init__.py
--- blendercal-orig/__init__.py 2007-10-09 19:24:14.0 +1300
+++ blendercal/__init__.py 2007-10-09 20:10:13.0 +1300
@@ -37,8 +37,8 @@
influence from Loic Dachary, especially in the bcdata.AnimationData().
"""
-# A decorator to catch any exception semi-gracefully. Sometiem later
-# this will create a Blender panel to show the exception.
+## A decorator to catch any exception semi-gracefully. Sometiem later
+## this will create a Blender panel to show the exception.
def exception(function):
return function
@@ -53,7 +53,6 @@
# A function that will parse the passed-in sequences and set the appropriate
# values in bcconf.
[EMAIL PROTECTED]
def ParseArgs(parse):
args = []
strip = lambda s: s.rstrip().lstrip().replace("\t", "").replace("\n",
"")
@@ -90,3 +89,5 @@
# Return args; since this will be False by default, we'll use this
# to determine if the user passed a --blendercal argument.
return args
+
+ParseArgs = exception(ParseArgs)
diff -r -u blendercal-orig/bcdata.py blendercal/bcdata.py
--- blendercal-orig/bcdata.py 2007-10-09 19:26:14.0 +1300
+++ blendercal/bcdata.py2007-10-09 20:11:30.0 +1300
@@ -25,7 +25,6 @@
if obj.getType() == t and not obj.getName().startswith("_"):
yield obj, obj.getData()
[EMAIL PROTECTED]
def SkeletonData():
# This function returns a single blendercal.bcobject.Skeleton instance
# and sets blendercal.bcobject.Skeleton.ARMATURE to the appropriate
Blender
@@ -54,7 +53,9 @@
return skeleton
[EMAIL PROTECTED]
+SkeletonData = blendercal.exception(SkeletonData)
+
[EMAIL PROTECTED]
def MeshData():
# This function returns a list of blender.bcobject.Mesh objects, one for
# each mesh in your Blender scene. The Cal3D notion of a Mesh is
actually more
@@ -256,7 +257,7 @@
# preventing another iteration of all the vertices here.
for i, v in enumerate(vlist):
weights = data.getVertexInfluences(v.index)
- total = sum(w for b, w in weights)
+ total = sum([w for b, w in weights])
for b, w in weights:
vertices[i].influences.append(bcobject.Influence(
@@ -300,7 +301,8 @@
return meshes
[EMAIL PROTECTED]
+MeshData = blendercal.exception(MeshData)
+
def AnimationData():
# This function demonstrates a new way of parsing and retrieving
animation
# data in Blender. With version 242 and above, users can call the the
@@ -369,7 +371,8 @@
return animations
[EMAIL PROTECTED]
+AnimationData = blendercal.exception(AnimationData)
+
def ExportData(filename, skeldata, meshdata, animdata, prefixfiles=False):
dirname = os.path.dirname(filename)
basename = os.path.splitext(os.path.basename(filename))[0]
@@ -419,3 +422,5 @@
print >> file(os.path.join(dirname, matfile), "w"), material
print >> cfg, "material=%s" % matfile
+
+ExportData = blendercal.exception(ExportData)
diff -r -u blendercal-orig/bcobject.py blendercal/bcobject.py
--- blendercal-orig/bcobject.py 2007-10-09 19:28:16.0 +1300
+++ blendercal/bcobject.py 2007-10-09 20:09:32.0 +1300
@@ -12,7 +12,7 @@
# hashable and unordered.
from sets import ImmutableSet
-CONCAT = lambda s, j="": j.join(str(v) for v in s)
+CONCAT = lambda s, j="": j.join([str(v) for v in s])
STRFLT = lambda f: "%%.%df" % bcconf.FLOATPRE % f
class Cal3DObject(object):
@@ -550,7 +550,7 @@
# If one UV is None, the rest will also be None.
if len(uvs) and (uvs[0][0] != None):
- self.maps.extend(Map(uv) for uv in uvs)
+ self.maps.extend([Map(uv) for uv in uvs])
submesh.vertices.append(self)
@@ -710,7 +710,7 @@
STRFLT(invertrot.z),
STRFLT(invertrot.w),
self.parent and "%d" % self.parent.id or "-1",
- "".join("##%s\n" % c.id for c in
self.children)
+ "".join(["##%s\n" % c.id for c in
self.children])
)
class Animation(Cal3DObject):
___
Soya-user mailing list
Soya-user@gna.org
https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Can Soya handle centre of mass not at origin?
Jan Ciger wrote: > ode-join.py is wrong. ODE has never supported this properly and the > error message was added to make this point explicit. My question was whether *soya* does anything to overcome this restriction. Delving into the code further, it seems that it makes no attempt to do so. I'm working on a patch to fix this now. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Can Soya handle centre of mass not at origin?
I'm trying to use Soya 0.13 with ODE 0.8, and running the ode-join.py tutorial, it falls over with this: ODE Message 2: mass must be > 0 in dMassCheck() File mass.cpp Line 44 ODE INTERNAL ERROR 2: The centre of mass must be at the origin. in dBodySetMass() Abort Earlier versions of ODE ignored this, but in 0.8 it seems to be regarded as a fatal error. Looking at ode-join.py, it appears to expect a body with a centre of mass that isn't at its origin to work. Is Soya meant to support this, or is ode-join.py wrong? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Error in _Body._reactivate_ode_body()?
Looking in body.pyx, I found this in _reactivate_ode_body(): vector_by_matrix(v, self._root_matrix()) vector_by_matrix(v, self._ode_parent._inverted_root_matrix()) chunk_get_floats_endian_safe(ode_chunk,v,3) dBodySetAngularVel(bid,v[0],v[1],v[2]) It looks as though the third line is meant to come first, i.e. chunk_get_floats_endian_safe(ode_chunk,v,3) vector_by_matrix(v, self._root_matrix()) vector_by_matrix(v, self._ode_parent._inverted_root_matrix()) dBodySetAngularVel(bid,v[0],v[1],v[2]) Is this right? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Patches to 0.13 for Pyrex 0.9.6
Here are some patches to help Soya 0.13 compile cleanly with Pyrex 0.9.6.1, and to fix a couple of bugs. Notes about the patches: #U# marks code that I commented out because it was generating unused code warnings. I found a few places where local variables were not initialised. It wasn't always clear what the correct initial value should be, so I marked these with POSSIBLE BUG. -- Greg diff -u -p -r -N -x .DS_Store -x build -x setup.py -x _ode.c -x _soya.c -x opengl.c -x sdlconst.c Soya-0.13/base.pyx Soya-0.13-new/base.pyx --- Soya-0.13/base.pyx 2007-01-16 10:43:07.0 +1300 +++ Soya-0.13-new/base.pyx 2007-10-09 19:15:51.0 +1300 @@ -60,7 +60,7 @@ CAN_USE_TEX_BORDER = 1 cdef Renderer renderer -cdef int MAX_LIGHTS, MAX_CLIP_PLANES, MAX_TEXTURES, MAX_TEXTURE_SIZE +cdef GLint MAX_LIGHTS, MAX_CLIP_PLANES, MAX_TEXTURES, MAX_TEXTURE_SIZE def get_max_texture_size(): return MAX_TEXTURE_SIZE @@ -113,8 +113,13 @@ cdef class _CObj: pass def __getstate__(self): - if getattr(self, "__dict__", 0): return self.__getcstate__(), self.__dict__ - else:return self.__getcstate__(), + cdef object d + try: + d = getattr(self, "__dict__") + except: + return self.__getcstate__() + else: + return self.__getcstate__(), d def __setstate__(self, state): self.__setcstate__(state[0]) @@ -136,8 +141,8 @@ cdef class _CObj: return clone -cdef chunk_to_string(Chunk* chunk): - return PyString_FromStringAndSize( chunk.content, chunk.nb) +#U#cdef chunk_to_string(Chunk* chunk): +#U#return PyString_FromStringAndSize( chunk.content, chunk.nb) cdef drop_chunk_to_string(Chunk* chunk): cdef string diff -u -p -r -N -x .DS_Store -x build -x setup.py -x _ode.c -x _soya.c -x opengl.c -x sdlconst.c Soya-0.13/c.pxd Soya-0.13-new/c.pxd --- Soya-0.13/c.pxd 2006-07-12 08:06:18.0 +1200 +++ Soya-0.13-new/c.pxd 2007-03-30 14:01:41.0 +1200 @@ -34,7 +34,7 @@ cdef extern from "math.h": float sin (float x) float tan (float x) float exp (float x) - float pow (float x, int n) + float pow (float x, float n) float ceil (float x) float floor (float x) diff -u -p -r -N -x .DS_Store -x build -x setup.py -x _ode.c -x _soya.c -x opengl.c -x sdlconst.c Soya-0.13/cal3d/model.pyx Soya-0.13-new/cal3d/model.pyx --- Soya-0.13/cal3d/model.pyx 2006-11-21 12:26:39.0 +1300 +++ Soya-0.13-new/cal3d/model.pyx 2007-03-30 14:01:41.0 +1200 @@ -677,8 +677,11 @@ cdef class _AnimatedModel(_Model): CalCoreModel_CreateCoreMaterialThread(self._core_model, i) CalCoreModel_SetCoreMaterialId(self._core_model, i, 0, i) CalCoreMaterial_SetUserData(material, i) - - CalRenderer_GetMapUserData + + # Greg Ewing, March 2007 ([EMAIL PROTECTED]) + # Following line commented out as it wasn't doing anything and was causing + # a compiler warning. POSSIBLE BUG. + #CalRenderer_GetMapUserData # This method is split in 3 ; this is a work-around for a bug in Pyrex diff -u -p -r -N -x .DS_Store -x build -x setup.py -x _ode.c -x _soya.c -x opengl.c -x sdlconst.c Soya-0.13/cal3d_wrapper.h Soya-0.13-new/cal3d_wrapper.h --- Soya-0.13/cal3d_wrapper.h 2006-05-21 10:43:18.0 +1200 +++ Soya-0.13-new/cal3d_wrapper.h 2007-03-30 14:01:41.0 +1200 @@ -188,7 +188,7 @@ extern "C" // CalCoreAnimation wrapper functions declaration // //// - CAL3D_WRAPPER_API struct CalCoreAnimation *CalCoreAnimation_New(); + CAL3D_WRAPPER_API struct CalCoreAnimation *CalCoreAnimation_New(void); CAL3D_WRAPPER_API void CalCoreAnimation_Delete(struct CalCoreAnimation *self); CAL3D_WRAPPER_API void CalCoreAnimation_AddCoreTrack(struct CalCoreAnimation *self, struct CalCoreTrack *pCoreTrack); @@ -231,7 +231,7 @@ extern "C" CAL3D_WRAPPER_API struct CalQuaternion *CalCoreKeyframe_GetRotation(struct CalCoreKeyframe *self); CAL3D_WRAPPER_API float CalCoreKeyframe_GetTime(struct CalCoreKeyframe *self); CAL3D_WRAPPER_API struct CalVector *CalCoreKeyframe_GetTranslation(struct CalCoreKeyframe *self); - CAL3D_WRAPPER_API struct CalCoreKeyframe *CalCoreKeyframe_New(); + CAL3D_WRAPPER_API struct CalCoreKeyframe *CalCoreKeyframe_New(void); CAL3D_WRAPPER_API void CalCoreKeyframe_SetRotation(struct CalCoreKeyframe *self, struct CalQuaternion *pRotation); CAL3D_WRAPPER_API void CalCoreKeyframe_SetTime(struct Ca
Re: [Soya-user] Character control ODE features
Zoltán Döme wrote: > This would enable game developers to use the physics subsystem for > managing AI/user controlled "standing" characters, by disabling ODE to > change the orientation of a body, so the programmer can manage the > rotations of the body. (Thus we could have a body react correctly to > collision/gravity, and also have it stand upright at all times, like > an FPS character). I'd be reluctant to try to force the behaviour of ODE objects like this. There could be all sorts of undesirable side effects. It would be better to come up with a set of constraints expressing the condition you want to maintain, and let ODE work the way it naturally wants to. Not sure offhand how you would do it exactly, but you might be able to do something with AMotor joints to apply a torque tending to restore the object to an upright orientation. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] label woes
marmoute wrote: > a simple workaround is to add > Freesan.tff (or any other font you wanna use) to the ./data/fonts/ > directory of your project. I find it's always a good idea to include my own fonts when using either soya or pygame. It's just too random whether a given system will have a suitable default font or will be able to find a default font at all. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] any optimization recommendations?
Souvarine wrote: > Actually the idea is to call the advance_time method of non visible > objects only once with proportion = 1 Ah, okay, that makes sense. > I've just tested this idea once, I havn't benchmarked it yet. But I > believe it can be a good optimisation. Am I an optimisation extremist ? As with any optimisation, you can't be sure of anything until you measure. And you really ought to measure *before* attempting any optimisation at all too see whether it's enough of a bottleneck to be worth bothering. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+ ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] any optimization recommendations?
Souvarine wrote: > Bodys that are not visible are > not rendered and advance_time method of non visible bodys is not called. ^^ Hey, whoah, that last bit sounds wrong. Positions etc. of animated object still need to be updated even if you can't see them, don't they? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Problems with ODE in 0.13
Running several of the ode tutorials, I get messages like ODE Message 2: mass must be > 0 in dMassCheck() File mass.cpp Line 44 which is a bit worrying, although most of them seem to work anyway. However, ode-join.py crashes with ODE INTERNAL ERROR 2: The centre of mass must be at the origin. in dBodySetMass() Abort which is not so good. :-( Do these work for anyone else? I'm using ODE 0.8, if that makes a difference. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] MacOSX, Soya, Python2.4 and input events?
marmoute wrote: Run it with pythonw2.4 and not python2.4. I tried that, but there doesn't seem to *be* a pythonw2.4 on my system. And I was given to understand that a pythonw wasn't supposed to be necessary with 2.4. I'm using 2.4.3 configured for a framework install. Is there something else I need to do besides giving --enable-framework to the configure script to get me a pythonw2.4? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] MacOSX, Soya, Python2.4 and input events?
I'm trying to get Soya 0.13 working with Python2.4 on MacOSX 10.4. It produces output, but doesn't seem to get any input events. It doesn't seem to be getting run as a MacOSX application properly. It has no icon in the dock, and Terminal's menu bar remains active when the Soya window is in front. The beach ball spins continuously, and any keyboard characters go to the Terminal window that it was started from. With Python 2.3, I would have taken this as a sign that I needed to run it with pythonw rather than python, but there doesn't seem to be a pythonw in 2.4. What am I supposed to do? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Soya 0.13 vs. Soya 0.13rc1
Have there been any important changes (bug fixes in particular) between Soya 0.13rc1 and the final 0.13 release? I'm asking because I downloaded 0.31rc1 earlier and I want to know whether it's worth getting the final release before I start working with it. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Python 2.5
Jan Ciger wrote: --- Soya-0.13/c.pxd 2006-07-11 22:06:18.0 +0200 +++ Soya-0.13-patch/c.pxd 2007-03-10 03:14:50.0 +0100 @@ -39,4 +39,4 @@ float floor (float x) cdef extern from "stdint.h": - ctypedef long intptr_t + ctypedef long long intptr_t I'm wondering whether something here should really be using uintptr_t instead of intptr_t. Does it work if you use ctypedef unsigned long intptr_t instead? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] new ode integration (0.13 RC1) questions
marmoute wrote: As a world can only have a single Space the creation of any new Space for a World will replace the old one (and transvase it's content into the new one). I hope it's possible for a single ode world to have more than one collision space. In my game I have two spaces, one for fixed objects and one for moving objects. I test the moving objects for collision with each other and with the fixed objects, but don't test the fixed objects for collision with each other (which obviously can't happen). Since I expect to have many fixed objects and only a few moving ones, this greatly reduces the amount of collision detection that must be done. each body (with collision detection) will be placed into the Space of it's parent World* and each Space will be placed into the Space of it's parent until you get the root space. Okay, so I could have two (non-ode) sub-worlds called fixed_objects and moving_objects, each with its own space. All I need then is the ability to tell it not to collide the fixed_objects space with itself. Is it possible to do that? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] BSP World added on repository
Souvarine wrote: I don't know SketchUp. You should try it -- it's fun!-) The reason I want to use it is that it has an extremely nice user interface, far ahead of any other 3d editor I've ever used. Looks like I'll have to either write my own BSP generator or adapt one from somewhere else... Thanks, Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] BSP World added on repository
Souvarine wrote: I just commited my work on BSP world for Soya on the subversion. I hope it will work for you :) This sounds very interesting. I've been thinking about trying to create a first-person indoor game engine using Soya, and this could be just the thing it needs. Are you planning to include anything for building the BSP tree, or will it rely on external tools for that? I ask because I'm interested in using SketchUp as a level editor, so I'd need another tool to generate the BSP tree if Soya wouldn't do it for me. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Client-server ODE physics
Philippe ENTZMANN wrote: Then comes my porposal : During 7 seconds, all the moves are deterministic. Why not pre-compute the ODE physics at the server-side and spread it to the client ? If you have enough server CPU and network bandwidth to do that, it sounds like a good idea. It would mean there was no chance of the clients getting out of step with the server or with each other. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] camera.back problem
Jiba wrote: Ok, I've added this compile flag (I prefer this solution to Greg's one, > because one may write new code and ignore that all char would need to be > explicitely marked as signed or unsigned). Certainly it's an easier way of fixing it in the short term, but I still think it would be better to aim at eliminating all such usages from the code in the long term. Code which relies on particular compiler options to work correctly (as opposed to just more efficiently) is fragile. If anyone ever forgets and compiles it without the required option, a very subtle bug comes back from the dead to bite them. Also it makes the code non-portable in another way, by tying it to the capabilities of a particular compiler. One day someone might want to compile it with a compiler that doesn't have an option for signed chars, and then they're faced with having to track down all the places that depend on signed chars and fixing them properly. Writing code that doesn't depend on the signedness of chars may require some discipline, but in my opinion it's better to learn that discipline than to go on writing non-portable code and patching over the problems. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] camera.back problem
souvarine wrote: I suggest to add -fsigned-char to soya's compilation flags to prevent this kind of problem to happend again. A better way would be not to write code that depends on the signedness of chars, since it's non-portable. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Ode : Physic simulation and Joint (tester needed)
Jacques Rebourcier wrote: - made some test, with correct performance, then try to integrate menu (diferent scenes) and widget, and now I have perf pb (cpu consumption constantly high and response time becoming bad with time) Have you tried disabling cyclic gc? I've found it to have quite bad effects on animation smoothness. Currently I'm keeping it turned off, and explicitly doing a gc at certain times, such as when switching levels. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] SDL doesn't cope well with FreeSans
Whenever I try to use the FreeSans font with SDL, either through PyGame or Soya, I get disappointing results. The characters come out slightly higglety-pigglety -- randomly displaced up or down a pixel or so from the baseline. Something about the calculation of the font height seems to be off, too. The fonts that come with MacOSX don't have these problems, so the fault doesn't seem to be with SDL or FreeType. Has anyone else noticed this? If it's a problem with the quality of FreeSans, can anyone recommend a free Helvetica-like font family that doesn't have this problem? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] ode physic engine integration
marmoute wrote: the coordinate of soya and ODE is not propertly converted between the ^^^ parent CoorSyst and the ode_parent CoordSyst) I hope that's a typo and you mean it *is* properly converted... * The application of Force vector is a pain since there is no automatic CoordSyst convertion Just for force vectors? Or did you really mean that "not" above? * Join is not yet supported (Maintly because my main goal is collision but it shouldn't be very hard to implement) That will be very important for my usage. I not only need to find collisions, but also add contact joints to handle them. I'm using joints for other purposes as well. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] ODE - Worlds and Bodies
marmoute wrote: In the new implementation I currently writing ode stuff will be integrated to the soya core. Every Body (fka Volume) will have the abilities to be (or not) ODE managed and every World maybe have ODE world property. That sounds very useful! The dichotomy between ODE and non-ODE objects is another thing that has caused complications in my current project. Body will automagicly go up the tree looking for a World with ODE support enabled Excellent! I'll look forward to the new version very much. You look to have good experience of soya with ODE I've actually only been using it for a couple of weeks, and I'm quite impressed by how easy it's been to get things working. I may be a good idea to have a little conversion on irc or jabber ([EMAIL PROTECTED]) I'm not really in the habit of using irc and the like; I tend to prefer mailing lists, since they don't require time synchronisation. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Resend: More patches
Sorry, forgot to attach the patches!
--
Here are another couple of patches for Soya-0.11.2.
(Haven't had a chance to upgrade to the latest
version, sorry -- hope you can incorporate them
if they're still useful.)
pudding/control.py:
Fixes crash on keycodes > 255, and allows Delete
as well as Backspace for erasing characters.
pudding/sysfont.py:
Does a better job of finding installed fonts on MacOSX
and associating them with the standard aliases (looks
in System fonts directory, recognises .dfont as well
as .ttf files) .
--
Greg
--- Soya-0.11.2-orig/pudding/control.py 2006-06-09 09:33:43.0 +1200
+++ Soya-0.11.2/pudding/control.py 2006-07-19 23:04:20.0 +1200
@@ -475,10 +475,10 @@
if key == sdl.K_RETURN:
self.on_return()
- elif key == sdl.K_BACKSPACE:
+ elif key == sdl.K_BACKSPACE or key == sdl.K_DELETE:
self.value = self.value[:-1]
self.on_value_changed()
- elif key != 0:
+ elif 0 < key <= 255:
if chr(key) in string.printable:
self.value += chr(key)
self.on_value_changed()
--- Soya-0.11.2-orig/pudding/sysfont.py 2006-07-20 20:41:28.0 +1200
+++ Soya-0.11.2/pudding/sysfont.py 2006-07-20 20:52:33.0 +1200
@@ -104,29 +104,33 @@
def initsysfonts_darwin():
-""" read of the fonts on osx """
+ """ read of the fonts on osx """
-paths = ['/Library/Fonts',
+ paths = ['/System/Library/Fonts',
+ '/Library/Fonts',
'~/Library/Fonts',
'/Local/Library/Fonts',
'/Network/Library/Fonts']
-fonts = {}
-for p in paths:
-d = os.path.expanduser(p)
-if os.path.isdir(d):
-os.path.walk(d, _fontwalk_darwin, fonts)
-return fonts
+ fonts = {}
+ for p in paths:
+ d = os.path.expanduser(p)
+ if os.path.isdir(d):
+ os.path.walk(d, _fontwalk_darwin, fonts)
+ fonts["sans"] = fonts["Helvetica"]
+ fonts["serif"] = fonts["Times"]
+ fonts["fixed"] = fonts["Courier"]
+ fonts["wingdings"] = fonts["ZapfDingbats"]
+ return fonts
def _fontwalk_darwin(fonts, path, files):
-""" walk the path directory trees """
-for font in files:
-if font[-4:].lower() != '.ttf':
-continue
-name = font[:-4]
-font = os.path.join( path, font )
-bold = 0
-italic = 0
-_addfont(name, bold, italic, font, fonts)
+ """ walk the path directory trees """
+ for font in files:
+ name, ext = os.path.splitext(font)
+ if ext in (".ttf", ".dfont"):
+ font = os.path.join( path, font )
+ bold = 0
+ italic = 0
+ _addfont(name, bold, italic, font, fonts)
___
Soya-user mailing list
Soya-user@gna.org
https://mail.gna.org/listinfo/soya-user
[Soya-user] More patches
Here are another couple of patches for Soya-0.11.2. (Haven't had a chance to upgrade to the latest version, sorry -- hope you can incorporate them if they're still useful.) pudding/control.py: Fixes crash on keycodes > 255, and allows Delete as well as Backspace for erasing characters. pudding/sysfont.py: Does a better job of finding installed fonts on MacOSX and associating them with the standard aliases (looks in System fonts directory, recognises .dfont as well as .ttf files) . -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Soya 0.12
Jiba wrote: Many Soya objects were having weird names; they have been renamed to more comprehensive names ^ You probably mean "comprehensible" (understandable). "Comprehensive" means something different (complete, all-inclusive). -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Suggestion - Material inheritance
Jiba wrote: Hum... it's a bit more complex in Soya, because the order in which > the objects are rendered may not follow the scene tree. You'd only have to rely on the OpenGL state in the display list of a Shape. Then there are only two possibilities -- a given face specifies its own material (using calls compiled into the display list), or it uses whatever material was set before calling the display list. In all other situations you can do whatever is necessary to figure out what material to apply to a Face. It needn't have anything to do with OpenGL state management. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Suggestion - Material inheritance
Jiba wrote: However, i think the new deforming system (again :-) can be easily extended to do that ; something like a MaterialSwitcherDeform. Instead of just "one-material inheritance", i'm thinking rather to a dictionary mapping old materials to the new ones, which would allow to change several materials. That sounds like it could be very useful. Some questions: Will it be possible to apply these deformations at any level in the tree, not just to Shapes? Will it be possible to change the mappings dynamically? If it's necessary to compile a new Shape for each combination of mappings, it doesn't sound like something you'd want to do frequently during a run. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Introducing the "Yet-in", the (yet-in)complete guide to soya 3D
Jiba wrote: > Someone else wrote: > I have to make is that the UML diagram looks extremely blocky, at > least on my machine. It seems very depending of the program you use for viewing the PDF. It looks nice for me in Preview on MacOSX, except that the attribute descriptions are too wide for the boxes meant to contain them. You might want to provide some extra room in the boxes, to allow for font differences between machines. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Mirrored shapes don't work?
Dunk Fordyce wrote: i dont think you can use the same display list for a mirrored object unless you specifiy that the vert order for faces is also flipped when drawing a mirrored instance. I think you could do that by setting the culling options before calling the display list, instead of putting them into the display list itself. i also think you'll run into troubles with ode without two seperate shapes. That might be so -- I don't know much about how ode treats its triangle meshes. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] suggestion about raypicking
souvarine wrote: I suggest to make a category bitfield system as in ODE. Every object would have a 32 bit wide bitfield Why limit it to 32? This is Python, we have long integers... -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] ODE - Worlds and Bodies
While you're reworking the ODE stuff, is there any chance of relaxing the restriction that an ode.Body be a direct child of an ode.World? From comments in the source, it seems that this restriction didn't exist once, but the relevant code is now commented out. I'm asking because I'd like to be able to have a collection of interconnected moving objects under a parent object that serves as an initial coordinate system, a node in the naming hierarchy and a place to implement behaviour relating to the collection as a whole. Without this ability, I'm having to build a rather complicated structure with two parallel hierarchies and duplication of functionality. It would be much simpler if I could do it all with a single hierarchy of Soya objects. Note that I'm not asking for the ability to put an ode.Body inside another ode.Body -- I can understand if that would be too hard. Just the ability to have other non-ode Worlds in between the ode Body and its World. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Mirrored shapes don't work?
Michael Edwards wrote: Not sure if it'd be worth it, but Blender has pretty excellent mirroring support, if you don't mind importing your models into that (it's free software, so, that's not so bad). That's not really an option. I'm using some specific features of SketchUp in a specific way. I'm not just building models of objects, I'm building a whole game level, with annotations that control the behaviour of objects, not just their appearance. Switching to another modeller would be a major upheaval. Besides, it would take a *much* bigger incentive than that to make me give up the SketchUp user interface. If you haven't tried it, you have no idea what you're missing. There's a free version now too, called Google Sketchup (as in beer, but not source, unfortunately): http://sketchup.google.com/ -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Suggestion - Material inheritance
Here's another feature suggestion: Inheritance of materials down the object hierarchy. In SketchUp, you can define a component with no material specified for some or all of its faces, and then apply different materials to different instances of that component. The faces which have no material inherit the material from further up in the tree. It would be handy if Soya Faces and Shapes behaved in a similar way. Currently I'm expanding this sort of arrangement on import and creating multiple Shapes with the same geometry but different materials, which seems rather wasteful. If Faces with no material were to inherit a material from further up, I would be able to share the Shape between instances, in the same way as the original SketchUp model. This would mean giving Worlds and Volumes a 'material' property that would be used as the default material in any sub-objects that didn't specify their own material. It seems like this should be fairly straightforward to implement, by making use of OpenGL's ability to push and pop various parts of its state. Whenever you encounter an object with a material, push the current state of the relevant OpenGL variables, set them up for the new material, render all the sub-objects, then pop the previous material state. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Mirrored shapes don't work?
Jiba wrote: About model deforming, i was thinking to a "static deform" > (not yet implemented but planned), which would have no > performance cost at all. Performance wasn't what I was thinking of. Rather, it would be inconvenient when building a model (particularly from a description generated by some external modelling tool) if mirroring transformations had to be handled by a different mechanism than all other transformations. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Mirrored shapes don't work?
Dunk Fordyce wrote: greg, why dont you just do the mirroring yourself? you say your using a custom importer/exporter so there should be no problem. The point is to be able to use the same Shape for left-handed and right-handed versions of an object, to save memory, display list space, etc. Currently I'm just creating two versions of the object manually in SketchUp. I could probably do that automatically in the exporter if I wanted, but it hasn't been worth the effort so far. It's not a big problem, it's just a bit disappointing that it *almost* works but not quite. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Mirrored shapes don't work?
Jiba wrote: I think it is a trouble with the culling system ; i'm going to investigate it. While you're at it, would it be possible to also arrange for front/back faces to be swapped when rendering in a mirrored coordinate system? That would be more efficient than having to use double-sided faces. BTW, in the future, the new model deforming API may be another way for mirroring models. Model deforming sounds interesting, but I'd rather not *have* to use it just to get a mirrored object. Currently I'm building models using SketchUp and loading them using a custom export/import script arrangement. It would be easiest if I could just use whatever transformation matrix was used in the SketchUp model, instead of having to figure out whether it's mirrored and do something different. On another topic, you can disregard what I said about Geoms earlier, since it seems it already works the way I wanted. Not sure why I thought otherwise -- there must have been something else wrong with my code. However, I've discovered another small limitation -- you don't seem to have provided individual access to the three collision functions (dCollide, dCollideSpace and dCollide2), instead providing one prepackaged recursive collision algorithm. That's handy, but it shouldn't be at the expense of access to the underlying functions, because the user might want to do things differently. As an example, for one application I have in mind I'd like to be able to test whether a particular object intersects anything else in the model. The natural way to do that would be to do dCollide2 between the geom of that object and the space for the model, but I can't, because dCollide2 is not exposed. Thanks, Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Mirrored shapes don't work?
If I create a Volume with some Faces and then mirror it by giving it a negative scale factor along one axis, the front and back faces get reversed. That's a bit annoying, but it can be worked around by making the faces double sided. However, if I create a Shape out of it and create a mirrored instance of the shape, it doesn't appear *at all*, even with double sided faces. Attached is a program that demonstrates the problem. It should display two pyramids, one of them upside down, but the second one is invisible. Changing the line pyramid2.scale(1, -1, 1) to pyramid2.scale(-1, -1, 1) i.e. a non-mirroring transformation, causes it to reappear. Anyone know what's going on? -- Greg # -*- indent-tabs-mode: t -*- # Soya 3D tutorial # Copyright (C) 2001-2004 Jean-Baptiste LAMY # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # modeling-1: Faces : the pyramid # requires the basic-* lessons. # Models are usually designed in Blender and imported in Soya (as in lesson basic-1.py), # but you can also create them from scratch, using Soya primitives. Learning this is # the purpose of the modeling-* tutorial series. # In this lesson, we'll build a pyramid, made of a quad base and 4 triangles. # Imports and inits Soya (see lesson basic-1.py). import sys, os, os.path, soya soya.init() soya.path.append(os.path.join(os.path.dirname(sys.argv[0]), "data")) # Creates the scene. scene = soya.World() # Creates the World that will contain the pyramid. As previously stated, the # pyramid is composed of 5 faces; this world is used to group those 5 faces # (exactly like a Frame can be used in Tkinter to group different widgets). # The pyramid's parent is the scene. pyramid = soya.World() # Creates the first face, the quad base of the pyramid. # The first argument of the Face constructor is the parent World (the pyramid), # the second is the list of vertices and the third is the material. # The number of vertices determines the Face's nature: # - 1: a plot # - 2: a line # - 3: a triangle # - 4: a quad # - +: a polygon # The vertices is a list of Vertex object. A Vertex is a subclass of Point that can have # some modeling attributes like colors or texture coordinates (we'll see them is further # lessons) The first argument of the constructor is (again) the parent, and the three # following one are the x, y and z coordinates. # As 3D object, Point, Vector or Vertex have a parent too, though they are not # considered as "children". The parent is used for automatic coordinates # conversion, which will be detailed in a further lesson. Here, the coordinates # are defined in the pyramid coordinate system. # The order of the vertices in the list determines which side of the face is # visible (for triangles, quads and polygons); you can get both side visible # by setting the "double_sided" attribute to 1. soya.Face(pyramid, [soya.Vertex(pyramid, 0.5, -0.5, 0.5), soya.Vertex(pyramid, -0.5, -0.5, 0.5), soya.Vertex(pyramid, -0.5, -0.5, -0.5), soya.Vertex(pyramid, 0.5, -0.5, -0.5), ]).double_sided = True # Similarly, creates the 4 triangles. # Here, we create different vertices ; you can also use the same vertex when 2 vertices # have the same coordinates and attributes. Both yields the same final result (including # in performance). soya.Face(pyramid, [soya.Vertex(pyramid, -0.5, -0.5, 0.5), soya.Vertex(pyramid, 0.5, -0.5, 0.5), soya.Vertex(pyramid, 0.0, 0.5, 0.0), ]).double_sided = True soya.Face(pyramid, [soya.Vertex(pyramid, 0.5, -0.5, -0.5), soya.Vertex(pyramid, -0.5, -0.5, -0.5), soya.Vertex(pyramid, 0.0, 0.5, 0.0),
[Soya-user] Patch to prevent crash in ode.GeomShape
Here's a patch to ode/shape.pyx to prevent a crash
if you try to create a GeomShape without providing
a shape.
--
Greg
--- Soya-0.11.2-orig/ode/shape.pyx 2006-06-09 09:38:04.0 +1200
+++ Soya-0.11.2/ode/shape.pyx 2006-07-12 13:04:48.0 +1200
@@ -99,8 +99,11 @@
cdef int i, nb_tris
cdef dSpaceID sid
- if shape is None:
+ if shape is None and parent is not None:
shape = parent._shape
+
+ if shape is None:
+ raise ValueError("No shape
passed or found in parent of soya.ode.GeomShape")
self.shape = shape
___
Soya-user mailing list
Soya-user@gna.org
https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] [SOLVED] Soya don't use my graphic card
Jiba wrote: Is there other people here using SDL >= 1.2.10 ? I'm using it with SDL 1.2.10 on MacOSX 10.4.4, and it *almost* works except for a strange problem: when the Python process *exits*, sometimes it complains about some memory being freed more than once. (I just tried to provoke an example, but it doesn't seem to want to do it now... drat!) I've no idea whether this is related to the SDl version, though -- I haven't tried it with any other version. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Patch: Joints attached to only one body
marmoute wrote: The Ode support is currently in complete rewrite. I'll do my best to integrate your work to this new intégration. Thanks. While you're working on that, here are some other thoughts I've had about the ode stuff: * Methods for setting joint parameters for the 3rd axis of a joint seem to be missing (some joints have such parameters, e.g. AMotor). * When adding geoms to a body, it seems that you have to add them directly to an ode.Body, not to a sub-object of the body. This makes it a bit awkward to construct bodies from a hierarchy of primitive objects. It would be nice if it would search up the hierarchy looking for a Body to attach the geom to (making appropriate coordinate conversions along the way). * It would also be nice if TriMesh-TriMesh collisions could be made to work properly. The ODE docs seem to suggest that this should be possible. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] GeomShape problems
Has anyone successfully used a Body with a GeomShape? I have a body sitting on a floor. The floor's geom is a GeomBox, and the body's geom is a GeomShape. But instead of the body resting on the floor, it partially sinks through it and gets caught on its upper corners. Any idea what might be going on here? -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Patch: Joints attached to only one body
Here's a patch for the attach() method of joints to allow one of the bodies to be None. This allows you to create a joint which connects a body to the fixed environment. -- Greg --- Soya-0.11.2-orig/ode/joints.pyx 2006-06-09 09:37:45.0 +1200 +++ Soya-0.11.2/ode/joints.pyx 2006-07-01 14:33:36.0 +1200 @@ -124,18 +124,30 @@ @type body2: Body """ + cdef dBodyID bid1, bid2 + if self.body1 is not None: self.body1._remove_joint(self) if self.body2 is not None: self.body2._remove_joint(self) - + + if body1 is not None: + # Make sure the bodies keep a reference to the joint so that + # the user doesn't have to + body1._add_joint(self) + bid1 = body1._bid + else: + bid1 = NULL + + if body2 is not None: + body2._add_joint(self) + bid2 = body2._bid + else: + bid2 = NULL + self.body1 = body1 self.body2 = body2 - dJointAttach(self.jid, body1._bid, body2._bid) - # Make sure the bodies keep a reference to the joint so that - # the user doesn't have to - body1._add_joint(self) - body2._add_joint(self) + dJointAttach(self.jid, bid1, bid2) ## getBody #def get_body(self, index): ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
[Soya-user] Setting position and orientation directly
I'm writing some code to build Soya objects from a description read from a file. I have a vector and 3x3 matrix representing the position and orientation of an object. As far as I can tell, the only way of using these is to figure out where abouts to stuff them into the 'matrix' property, which is just a big linear array of numbers. I think I've worked out what needs to go where, but I was wondering if there were a higher-level API for doing this that I'd missed somewhere. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
Re: [Soya-user] Alpha channel messes depth buffer?
snaipperi wrote: As you can see, the right side displays like it should, but on the left side the rear grass model appears in front of the closer model.. I think this is an unavoidable consequence of the way Soya uses OpenGL to handle partial transparency. Not sure of the details, but probably what it's doing is making one pass over the scene to render all the opaque parts with full depth buffering, and then a second pass for the translucent parts with depth buffer testing but not updating. What that means is that opaque objects will correctly occlude other opaque or translucent objects, but the ordering between different translucent objects is not controlled by the depth buffer. This is really about the best that can be done using a pure depth-buffer algorithm. If it makes a difference (as it does in your case) you'll just have to be careful about the ordering of your alpha-textured objects. -- Greg ___ Soya-user mailing list Soya-user@gna.org https://mail.gna.org/listinfo/soya-user
