#1 2015-02-13 19:05:44

angjminer
Member

bullet in tesseract

so ive been working on bullet integration,(this awesome engine needs floating leaves falling from trees)
and so far ive just about got level collision mesh generation done.

so i decided to run some time tests,
this video shows the generation for three different levels.

http://youtu.be/FOnMQRyBEvk

first 2 come with tess, Complex, and Steelribs.
last is from
"Metric (WIP) by Pritchard" he was asking about the time it took.

overall i think 235,857 triangles only taking about 10 seconds(although i need a progress bar),
is completely bearable.
and it may even go quicker when the debug draw is off.

just thought i would share,

thanks guys for the hard work you put into this,

angjminer

todo:
auto on level load.
regen when switching from edit to play mode.
save out *.bullet for faster load times.
give you the option of generating manually, in case you want to wait.
oh ...... and a progress bar for the more complex conversions(so you dont think it froze)

Offline

#2 2015-02-14 01:48:24

chasester1
Member

Re: bullet in tesseract

Definitely something that been needed. Do you plan on implementing any more physics based commands, say movable boxes :0. You can easily do the on switch by doing it with the other world operations that occur during the switch, and there is a command for the progress bar, which you can find both on a full window and a small progress bar in the upper right corner of the screen. If you would like i could outline were these are and how to implement them into your code (assuming i saw your source).

chasester

@edit
this could be added into the map file, it would be fairly simple to add this info as a cache and the map file is already fairly small.

But the most effient way to handle this, and the way most voxel and marching cube based meshs are handle are through a limited, physics set, only referencing mesh directly surrounding moving objects, rather then testing the entired of the mesh, tho the current map mesh based physics is fairly effiencient, you could probably look at that for optimization. :0

Last edited by chasester1 (2015-02-14 02:12:41)

Offline

#3 2015-02-14 03:23:26

angjminer
Member

Re: bullet in tesseract

Movable objects that tumble properly are the next thing on the list after I make sure everything is going well with the level mesh creation.if you check out my latest videos on YouTube you'll see what I have so far. (There is a newer one than the one above). The ultimate goal for me is fracture meshes, walls you can blow holes in.;)  but , one step at a time. I may rewrite the debug draw code I borrowed from the intensity engine, it drops the frame rate too much for my liking, although very enginious it's not reliable enough when you have a huge amount of triangles.    Thank you for your offer to help, I may have to take you up on that, BTW once what I am doing is usable I am going to merge it with the code I have on github, so it can be played with by everyone.

Offline

#4 2015-02-14 04:39:36

chasester1
Member

Re: bullet in tesseract

Ya sounds good

@blowing up walls
This is quite possible using the heightmap brush (already in place) (in edit mode press space to deslect and then press h to enter hightmap edit mode, then scroll to see, b + scroll changes brushes). This works well in a 2d directional sense but it may suffer on 3d conjoining parts. Converting this from a 2d height map brush to a 3d voxel brush would be fairly simple (and slightly over my head) but it would technically work in the same way. Then applying this on each explosion would make wall blow, and then send the info across (which is already in place used for multiplay editing).

You probably want to make a material called unbrakeable, would would make it impossible to destroy or modify these cubes, (and maybe a vlayer to add a tolerance similar to valpha which makes things harder to break, or more resistant.

This would make some pretty cool gameplay, and visual effects, which would be less hacky or ridgid as some games have done thus far.

But obviously this would require a ton of work, by easy i mean 100+ hours :) But physics would be a first for sure.

@debug draw mode
Look at the outline function in renderva.cpp VAR(outline, 0, 0, 1). This variable controls the outlining functionality in editing (in editmode while editing type outline 1) it basically shows the mesh and the wireframe, you should be able to use that code. The function renderoutline() has the bulk of the code, looks like gl calls. That probably the most efficient way of rendering it.

@physics
Do you plan on integrating bullet into the engine, or are you looking to write your own? (I was cautionary about integrating bullet cuz it is quite bulky at times, but it would provide some great power).
I was watching your frame rate drop in your video, what is the specs of your computer (cpu memory gfx card)?

@edit - after watching video
your function should be ran on exiting editmode not entering it
but i wouldnt even run your function without a remip becuase that will cut the amount of tri in half in most cases, this is why your fps was dropping towards the end of the video, a remip would have majorly improved your frame rate, because not only were you rendering 2x the tris you were outlining, and meshing 2x as many.

I think you should look at automatically doing a remip at the top of your function, and/or just do this when a user calls the remip console command. Because on larger maps it will take much longer and this will become a nascence if they leave and reenter editmode. remips are automatically done on save.

Last edited by chasester1 (2015-02-14 05:02:01)

Offline

#5 2015-02-14 15:44:26

angjminer
Member

Re: bullet in tesseract

i am doing the programing and shader work on my laptop, so i dont take my desktops components for granted, also some things that work for nvidia with no issue, fail miserably on ati. so i figure i will play it safe and to the dev work on the laptop(acer 4 g ram ,AMD Radeon HD 6520G) kind of low end by todays standards. without the debug draw, frame rates go back to normal, so i guess for now ill go back to that when it becomes more of an issue, its one line of code that makes it happen right now, so it wont be difficult to work with later. this is from the intensity port of sauerbraten, i plan on writing my own later.

//temp borrow from intencity engine
btIDebugDraw* m_debugDrawer;
// Sauer coordinates are in 'cubes', not metres as in Bullet
#define SAUER_FACTOR 17.0
// Reverse y and z axes
#define FROM_SAUER_VEC(sauervec) ( btVector3(sauervec.x/SAUER_FACTOR, sauervec.z/SAUER_FACTOR, sauervec.y/SAUER_FACTOR) )
#define TO_SAUER_VEC(sauervec, btvec) { sauervec.x = btvec.x()*SAUER_FACTOR; sauervec.y = btvec.z()*SAUER_FACTOR; sauervec.z = btvec.y()*SAUER_FACTOR; }

class SauerDebugDrawer : public btIDebugDraw
{
    int m_debugMode;
public:
    SauerDebugDrawer() : m_debugMode(0) { };
    virtual void drawLine(const btVector3 &from, const btVector3 &to, const btVector3 &fromColor, const btVector3 &toColor)
    {
	vec sauerFrom, sauerTo;
	TO_SAUER_VEC( sauerFrom, from );
	TO_SAUER_VEC( sauerTo, to );

	#define VEC_TO_COLOR(it) \
	    ((int((it.x()*0.5+0.5)*255)<<16) + (int((it.y()*0.5+0.5)*255)<<8) + int((it.z()*0.5+0.5)*255))
	particle_flare(sauerFrom, sauerTo, 0, PART_STREAK, VEC_TO_COLOR(fromColor));//,1);
    }

    virtual void drawLine(const btVector3 &from, const btVector3 &to, const btVector3 &color)
    {
	drawLine(from, to, color, color);

    }
        virtual void draw3dText (const btVector3 &location, const char *textString)
        {
            vec sauerLocation;
            TO_SAUER_VEC( sauerLocation, location );
            particle_text(sauerLocation, textString, PART_TEXT, 0);
        }
        virtual void drawContactPoint (const btVector3 &PointOnB, const btVector3 &normalOnB, btScalar distance, int lifeTime, const btVector3 &color) { }
        virtual void reportErrorWarning (const char *warningString) { printf("Bullet warning: %s\r\n", warningString); }
        virtual void setDebugMode(int debugMode) { m_debugMode = debugMode; }
        virtual int getDebugMode() const { return m_debugMode; }
};
/////////^^^^^^^^^^^^temp borrow from intencity engine^^^^^^^^^^^^^^^^/////////////////////////

Offline

#6 2015-02-14 18:39:25

chasester1
Member

Re: bullet in tesseract

my guess is that you are rendering particles for the entire maps mesh, instead of just the area in the render space, which means that all of these streak particles are being sent to the render buffer, and having to be eliminated in the zbuffer, instead of doing simple culling. You may want to add a simple command to check to see if the to or from point lie with in the camera renderable space (the near and far of the camera, this will speed it up greatly.

 virtual void drawLine(const btVector3 &from, const btVector3 &to, const btVector3 &color)
    {
        vec v;
        vecfromyawpitch(player->yaw, player->pitch, 0 , 0, &v);
        float f = vec(player->o).sub(from).normalize().dot(v);
        float t = vec(player->o).sub(to).normalize().dot(v);
        if(f < 0 && t < 0) return;
	drawLine(from, to, color, color);

    }

I do believe thats what you need, this is only been desk checked i dont have your code so i cant actually right the actual code.

But basically get the normalize vec of the diection of the camera ln 1; sub the players position from the from point of the particle on the mesh, and nomalize it ln2a; then dot product this with the facing direction of the camera. Any negative number means that the point is > 180 away from the point (or it is behind the camera; any positive number means that it is infront of the camera (this basically gives you the degrees in radians between the point and the camera.

If you get random errors please tell me them i may have messed something up, i tend to make those stupid mistakes :)

chasester

Last edited by chasester1 (2015-02-14 19:03:57)

Offline

#7 2015-02-16 17:47:40

angjminer
Member

Re: bullet in tesseract

chasester1 wrote:

my guess is that you are rendering particles for the entire maps mesh, instead of just the area in the render space, which means that all of these streak particles are being sent to the render buffer, and having to be eliminated in the zbuffer, instead of doing simple culling. You may want to add a simple command to check to see if the to or from point lie with in the camera renderable space (the near and far of the camera, this will speed it up greatly.

 virtual void drawLine(const btVector3 &from, const btVector3 &to, const btVector3 &color)
    {
        vec v;
        vecfromyawpitch(player->yaw, player->pitch, 0 , 0, &v);
        float f = vec(player->o).sub(from).normalize().dot(v);
        float t = vec(player->o).sub(to).normalize().dot(v);
        if(f < 0 && t < 0) return;
	drawLine(from, to, color, color);

    }

I do believe thats what you need, this is only been desk checked i dont have your code so i cant actually right the actual code.

But basically get the normalize vec of the diection of the camera ln 1; sub the players position from the from point of the particle on the mesh, and nomalize it ln2a; then dot product this with the facing direction of the camera. Any negative number means that the point is > 180 away from the point (or it is behind the camera; any positive number means that it is infront of the camera (this basically gives you the degrees in radians between the point and the camera.

If you get random errors please tell me them i may have messed something up, i tend to make those stupid mistakes :)

chasester

thats exactly whats going on, and you are correct,
ill be repairing that as soon as i get the bullet ents "newent bulletent" working,
i have them broke out and rendering(not to big a deal),
now i need to assign collision boxes and get some interaction happening,
I do have to say this though,
it appears as if the 2 physics engines are going to play nice together with out  the need to disable the original.
if bullet is disabled the bulletents just wont move,
I like that. I am not ready to do a gun in bullet yet.

I may hijack the model cfg for weight, joints and such,
not sure yet.
might be to much in one file.
needs to be easy to grasp whats going on. 

after it is said and done you may be able to choose between the engines, but for now a hybrid is fine with me.

Offline

#8 2015-02-17 16:12:26

angjminer
Member

Re: bullet in tesseract

http://youtu.be/tBlCVN_VSlA
still have plenty to do, but it is coming along nicely, for the amount of time i have in it. baby steps.

Offline

#9 2015-02-17 16:41:29

eihrul
Administrator

Re: bullet in tesseract

While this is kind of cool, I still more hoped to have in the future some type of smaller homegrown rigid body engine based on the MPR collision already there. Since while Bullet is not the worst physics library, it still represents another external dependency that has to be mucked with on all platforms. Tess has a lot of the fundamentals in place to do its own rigid body, its just a matter of someone bothering to code up some of the slightly nastier bits.

Now, even as regards external physics engines, building a mesh of the level is entirely meh, since the actual octree cubes are far better convex primitives against which to do collision. I know at least ODE allowed you to plugin your own scene representations, but can't say for Bullet.

Offline

#10 2015-02-17 19:00:00

angjminer
Member

Re: bullet in tesseract

eihrul wrote:

While this is kind of cool, I still more hoped to have in the future some type of smaller homegrown rigid body engine based on the MPR collision already there. Since while Bullet is not the worst physics library, it still represents another external dependency that has to be mucked with on all platforms. Tess has a lot of the fundamentals in place to do its own rigid body, its just a matter of someone bothering to code up some of the slightly nastier bits.

Now, even as regards external physics engines, building a mesh of the level is entirely meh, since the actual octree cubes are far better convex primitives against which to do collision. I know at least ODE allowed you to plugin your own scene representations, but can't say for Bullet.

I agree whole heartedly about the octree, this was just the fastest way to get the ball rolling.

I am trying to be as non invasive as possible, so its just an option, if bullet isn't there it just works as usual.

I brought the movable code over from sauerbraten and it works fine(wasn't to much of a hassle either), and i may not be the man for the task,
but yes i agree with you, using the mpr that's already there would be great, i just need something working to tear apart,

so i figured i would get this going, share it when it works,
then start tearing bullet apart to get just the bare minimum for it to work and use that as a modal to write the needed parts,
extracting bullet from the equation in the process.

i know its a lot of steps to go through, but i figure if i follow tess' coding style as closely as possible, i should end up with something that doesn't ugly up what you've done already, is easy to understand, and isnt required for "normal" execution.

the goal is something along the lines of a "enhancedphys.cpp/h" and 30 or so lines injected into the current code.(probably a little too optimistic )

getting the level to fracture in a believable manner is one of the things i am drooling over, and if i can do that in a way that is acceptable ,, well,, :)
you have made this thing so visually appealing i just couldn't help my self.

worst case scenario: someone can add bullet physics to tess without much fuss.

PS. thankyou for all the hard work and dedication youve put into this.
I just wanted to share what i am doing with all of you.
ill be getting XenoCollide & Game Programming Gems 7 soon, :)

Offline

#11 2015-02-19 23:21:25

chasester1
Member

Re: bullet in tesseract

very nice tho the movable class is super bloated but im sure you'll skinny it out :)

Offline

#12 2015-02-20 16:14:52

angjminer
Member

Re: bullet in tesseract

Offline

#13 2015-02-21 14:18:14

spikeymikey0196
Member

Re: bullet in tesseract

This image is completely relevant..

126007.jpg

Offline

#14 2015-02-21 15:57:04

angjminer
Member

Re: bullet in tesseract

spikeymikey0196 wrote:

This image is completely relevant..

http://files.sharenator.com/126007.jpg

:) , but to be honest what ive done pales in comparison to tesseract it self.

eihrul wrote:

While this is kind of cool, I still more hoped to have in the future some type of smaller homegrown rigid body engine based on the MPR collision already there. Since while Bullet is not the worst physics library, it still represents another external dependency that has to be mucked with on all platforms. Tess has a lot of the fundamentals in place to do its own rigid body, its just a matter of someone bothering to code up some of the slightly nastier bits.

Now, even as regards external physics engines, building a mesh of the level is entirely meh, since the actual octree cubes are far better convex primitives against which to do collision. I know at least ODE allowed you to plugin your own scene representations, but can't say for Bullet.

now that ive gotten this far , think its time to see if i can get this working with whats already there.
that would be even more awesome.
so within the next week or so, my goal is to do just that.
i really like what bullet has to offer,
but, because of my intentions,
i really want to give to tess.

see you in a bit. :)

Offline

#15 2015-02-24 07:01:55

Sturmamphen
Member

Re: bullet in tesseract

Interestingly enough, you weren't the only one to try this recently.  https://www.youtube.com/watch?v=nCgYaNjUbjQ&sns=tw

Offline

#16 2015-02-24 13:57:06

angjminer
Member

Re: bullet in tesseract

Sturmamphen wrote:

Interestingly enough, you weren't the only one to try this recently.  https://www.youtube.com/watch?v=nCgYaNjUbjQ&sns=tw

checking it out now, i am curious to see where they get their tri list from for the level collision mesh, i made sure i was doing it in a completely different manner from intensity, i am kind of excited about doing it the way eihrul suggested, mostly because it would get rid of an extra step, and ,it would look pretty ba with debug draw on. :)

Offline

#17 2015-03-11 14:37:54

angjminer
Member

Re: bullet in tesseract

https://github.com/angjminer/bullet-tesseract

this is by no means complete, still needs bullet physics applied to the weapons etc, but it is a good jump.

BE WARNED it is ugly.

search for //angelo
new and delete are commented out of tools.* because they get included with <new> in bullet,

look at the Makefile to see whats linked.
bullet needs to be built but is in /extralibs.

it is set up to rotate around the mesh's origin, so youll need a mesh whose origin is at the center of mass for it to look correct, the collision box creation needs some tweaking, may need to switch x and z around if its off in debug draw.

adding the bullet ent works like usual
"newent bulletent"
gets reset like the other ents.
was following along with how everything else was done as closely as possible.

hope someone finds this usefull.

angelo

Offline

#18 2015-03-11 20:39:09

Goober
Member

Re: bullet in tesseract

Thanks for sharing your progress! It appears to be very impressive, I'll definitely take a look at it.

Out of curiosity, are you releasing your code under the zlib license, just like Tesseract & Sauer?

Offline

#19 2015-03-11 23:39:39

angjminer
Member

Re: bullet in tesseract

Goober wrote:

Thanks for sharing your progress! It appears to be very impressive, I'll definitely take a look at it.

Out of curiosity, are you releasing your code under the zlib license, just like Tesseract & Sauer?

sorry , i didnt think it would be something that actually got used, but if any one wants to use parts directly.

its the same as tesseract/sauerbratens code.

direct copy from debug draw in syntencity, and quaternion to euler from an irrlicht example, is clearly marked,
just leave acknowledgment to those guys in those snippets.

Offline

#20 2015-03-12 00:43:56

Goober
Member

Re: bullet in tesseract

Thanks! I may have a use for it in a project I'm working on, so just wanted to make absolutely sure I knew the license it was under before I decide if I'm going to be using it :)

I have a question however, I'm receiving the following error when attempting to build. Using CodeBlocks on Windows 8.1.

||=== Build: client64 in tesseract (compiler: GNU GCC Compiler) ===|
..\shared\cube.h|53|fatal error: SDL2/SDL.h: No such file or directory|
||=== Build failed: 1 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

Am I missing a file that's required to build the solution?

Offline

#21 2015-03-12 13:24:05

angjminer
Member

Re: bullet in tesseract

Goober wrote:

Thanks! I may have a use for it in a project I'm working on, so just wanted to make absolutely sure I knew the license it was under before I decide if I'm going to be using it :)

I have a question however, I'm receiving the following error when attempting to build. Using CodeBlocks on Windows 8.1.

||=== Build: client64 in tesseract (compiler: GNU GCC Compiler) ===|
..\shared\cube.h|53|fatal error: SDL2/SDL.h: No such file or directory|
||=== Build failed: 1 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

Am I missing a file that's required to build the solution?

look in the project settings and make sure it is looking in the correct directories, youll also need to set up the library settings as well (what to link to).
i dont recall mucking with the codeblocks project, i was using kdevelop, compiling with the Makefile.
so you may have more work to do to get it building on windows.
you also need to build the bullet libraries, and make sure to look at the makefile for proper order to link against them, it will refuse to build if they are linked in the wrong order.

Offline

#22 2015-10-15 03:08:44

OnlyTheGhosts
Member

Re: bullet in tesseract

eihrul wrote:

While this is kind of cool, I still more hoped to have in the future some type of smaller homegrown rigid body engine based on the MPR collision already there. Since while Bullet is not the worst physics library, it still represents another external dependency that has to be mucked with on all platforms. Tess has a lot of the fundamentals in place to do its own rigid body, its just a matter of someone bothering to code up some of the slightly nastier bits.

Now, even as regards external physics engines, building a mesh of the level is entirely meh, since the actual octree cubes are far better convex primitives against which to do collision. I know at least ODE allowed you to plugin your own scene representations, but can't say for Bullet.

Very good point. It would be nicer that way, even if the resulting physics are a bit simplistic.

I would guess some will work on the Bullet idea, others try other methods. I even considered NDE at one point. Good old fashioned ODE would at least give the game workable elevators.

Last edited by OnlyTheGhosts (2015-10-15 12:30:05)

Offline

#23 2015-10-15 22:22:26

Hypernova^
Member

Re: bullet in tesseract

Elevator/platforms are in Sauerbraten if you'd like it. Along with triggers you can do some cool stuff, as seen in Sauerbraten singleplayer campaigns such as Lost.

Last edited by Hypernova^ (2015-10-16 01:38:01)

Offline

#24 2016-05-15 20:30:56

MirceaKitsune
Member

Re: bullet in tesseract

Is there any news on this? It sounds like a great improvement, and I'd like to see it making it to master or an important fork! An engine witch such great visuals definitely needs a great physics engine in the mix, and Bullet is the best in the FOSS world.

Offline

Board footer