Forum Replies Created
-
Posts
-
Attempt #1 is now up at develop!
There’s a simple test in the tests dir called ‘constraints.monkey2’. It’s just a basic chain of cubes, but it seems to work OK.
One weird thing is the chain should be ‘anchored’ by the cube at the top, and it sort of is, however the bottom cubes shouldn’t touch the ground but they do a little, not sure what’s up there yet…
I know little to nothing about constraints though! Should I just start with the simple 1 body, 1 pivot point2point type? How does/should this work? What would be a good little demo for this?
Actually, I’m up for having a go at getting a point2point constraint style component (or whatever) going right now, got nothing else on.
Hmm, that’s weird, bullet is using references instead of pointers here.
The easiest way to deal with this right now is probably to just add pointer versions of the ctors, eg:
btPoint2PointConstraint(btRigidBody* rbA,btRigidBody* rbB, const btVector3& pivotInA,const btVector3& pivotInB):
btPoint2PointConstraint(*rbA,*rbB,pivotInA,pivotInB){}btPoint2PointConstraint(btRigidBody* rbA,const btVector3& pivotInA):
btPoint2PointConstraint(*rbA,pivotInA){}Add this directly to the btPoint2PointConstraint.h file below the existing ctors – I haven’t tested it but it compiles at least. The nicer way is probably to subclass btPoint2PointConstraint and add the new ctors there, but this should get you going for now.
No idea why he’s done it this way, the joys of c++!
I’d recommend putting w,h in separate params instead of in the args array. That way you can use the same idea for non-int arrays too if necessary.
Actually, you’ve just given me an idea for how to add this to mx2cc! This is a bit tricky because it also has to be able to deal with 3d, 4d, 5d etc arrays, and I had been playing with syntax for an ‘arrays within arrays’ style initializers, but it was all pretty ugly, would probably have require a new kind of separator or grouping syntax/token and was generally un-monkey-like.
But the simplest solution would be to allow users to initialize new ‘sized’ arrays, eg: New Int[2,2]( 1,2,3,4 ). I don’t think this breaks any existing syntax and should be fairly easy to do (I hope) and while it’s a little inconvenient having to specify sizes instead of inferring them from data (which I could still add later I guess) it’s an improvement over what’s currently available, ie: nothing.
Can you post the stuff you’ve added to bullet.monkey2 (or all of it)?
Oops, please try again now.
If it’s still borked, please try executing an updatemods.bat first. The mx2cc builds scripts were missing zlib…
New zlib module and data buffer compress/decompress methods have been pushed to develop branch.
Can you try git pulling again?
I added a tweak to std module.json late last night which might fix this…
Also, I recommend you update the compler too – you’re on v1.1.09 but mx2cc is up to 1.1.12 now. Mixing older compiler with newer modules is likely to cause problems sooner or later…
To update mx2cc, just execute the updatemx2cc script after git pulling.
Looks like a bug in mx2’s handling of int uniforms – possible fix now pushed to develop.
Also, you never seem to use debug mode! I know it’s a bit rough, but many of your issues always cause some kind of debug error for me which makes them quite easy to find…
It’s probably time I added a zlib module – will do this soon so stay tuned for compress/decompress data buffer methods.
Hi,
You should leave the ctor arg to new UniformBlock as 3. Why did you change this to 4? With it set to 4 I get a runtime error trying to bind SourceTexture.
This arg refers to the ‘type’ of uniform block being created, where ‘3’ means ‘material’ uniforms, so they get a ‘m_’ prefix. Other uniform types include ‘render’ which have an ‘r_’ prefix and instance which has an ‘i_’ prefix etc. There is no real logic to these I’m just making them up as I go. It’s highly likely there will end up being lighting and scene uniform block types too with “l_” and “s_” prefixes (maybe) and all these uniform block types will eventually get enumed preventing lots of confusion here. The base class of PostEffect should probably be the one creating the uniform block anyway, but the PostEffect system is way underdeveoped and I’m really just experimenting with the shaders right now so it’s likely to stay this way for a while.
Anyway, leaving ctor uniform block type as 3 and SetFloat mousepos enabled I can run the demo and get the same dodgy greenish cube, but shader isn’t using mouse pos yet so that’s what I’d expect.
It looks like discontinuities at the edges of each terrain, perhaps the normals are being incorrectly generated here – will take a look at it.
But even if there is something up here, there will always be discontinuities at the edges I think (except in cases like this where terrains are totally flat) as the vertex normals wont be correctly generated at the edges as they aren’t actually connected to neighboring edge.
This is actually pretty close to how the original terrain that was in there last year worked though (except each tile was just an index buffer and they all shared the same mega vertex buffer) and I think I may resurrect it so hold tight and this may be built in soon!
The other usefull thing to know here is how multiplying matrices has the effect of ‘chaining’ a sequence of transforms together.
So say you’ve got 2 entities, and a point in local space of one of the entities, and you want to transform it into the local space of the other entity, you can do something like -entity2.Matrix * entity1.Matrix * point. This will transform a point from entity2’s local space to entity1’s local space. Note that matrix multiplication is not commutative (eg: matrix1*matrix2 is not the same as matrix2*matrix1) although it is associative (eg: (matrix1*matrix2)*matrix3 is the same as matrix1*(matrix2*matrix3)) and should generally be read ‘right to left’ (eg: the above first transforms point by entity1.Matrix and then by -entity2.Matrix). So by precalculating matrices like this, you can actually store a complex sequence of transforms in a singe matrix. This is what those weird sounding matrices like ‘ModelViewProjectionMatrix’ are actually doing, transforming from model space to view space to ‘clip’ space (another topic!)…
And that’s it – that’s most of what I know about 3d!
Use something like entity.Matrix * vertex.position, eg:
1Local v2:Vec2f = from_camera.ProjectToViewport( Self.Matrix * v.position )The matrix multiplication transforms the Vec3f position from one coord space (ie: local space) to another (ie: world space).
To get from world space to local space instead, use the inverse matrix, eg: -entity.Matrix * worldPos.
