#26 2015-12-05 20:35:11

chasester
Member

Re: Rival: Cube/tesseract mod

This can be used any time that you pass anything into a buffer, i.e. the map files. Also I dont know what sauers server/clients hand shake protocol actually looks like. But for security reasons you could take that buffer and pass it through an encryption algorithm and decrypt it on recieved. This would prevent packet sniffing and packet spoofing (not that that would be a real problem but it would be easy to write a basic encryption so that you aren't passing just rawdata). Also it would stop more advance hacks using external programs to try and manipulate packets (not a big deal for you cuz it would be easier to just modify the source since it is open :)

chasester

Offline

#27 2015-12-05 22:15:14

Hypernova^
Member

Re: Rival: Cube/tesseract mod

Thanks for the security tips.  My development has always been too focused on the game itself, I appreciate when people get me to think outside my box :)

Offline

#28 2015-12-10 02:36:24

a_teammate
Member

Re: Rival: Cube/tesseract mod

Ah sorry for my late reply.

@entities:
Ive talked with Hanack about your approach and he indeed also meant those approaches are fundamentally different actually (scenegraph vs bidirectional-property-graph, one beeing hiarchical and hence can easier dominate performance wise, while the bidirectional-graph allowing more combinations but need more caretaking when implementing to not kill performance). So it seems two different systems are abroad, nice ^^


chasester wrote:

@Shaders
I am working with lord KV (as1,as2,shader wizard) to help him build as3 on the rival engine (using the angelscript interface), and to improve the shader end of the engine. One of the last things I will do before multiplayer is try to get geometry shaders, or something similar into the engine, to help improve speed and performance, and to allow for some better graphical options.

Good idea to be open for newer shader stages :) With geometry shaders you'd probably could do some more advanced culling. (dunno about tesseract, but sauerbratens culling system is pretty basic. If that stayed the same you probably could gain some performance by renewing it)

@source
hm too bad, you wont release the source, i hope you'll redecide about that one time

chasester wrote:

Ps: I love your version control feature that looks very useful

Pss: if you guys are still a cube 2 fork does this mean that you plan on staying playable with the current cube 2 build. If so I feel you are gonna run into problems implementing some more useful features1

PPSS: I thought this engine died, Lol mentioned your particle system the other day to someone lol And I love the work you are doing :) ++1

PPSSPPSPSPSPSP: This is the last one :) feel free to email me at chasester123@gmail.com, You seem to have a very good gameplan as far as where you what inxor to grow.

Thanks for the warm words :) yeah its actually pretty similar to yours ^^ it seems those steps are mostly logical :D

Ah and no, dont worry: we completely broke compatibility with Sauerbraten and won't hesitate to do that in other places in the future. However we will provide importers in time for old content.


chasester wrote:

@edit
Looking at your server API structure stuct position::rool is a misspell of roll and you should use a transform matrix this is more efficient and would allow for scale of nodes as well. Also an ifloat interface rather than using a float type because floats using floating decimal points which is harder to keep the accurcy of the packet then an ifloat (an i float is int a = float *1000; this will give you the accurcy and keep you in a good range for the values. If you dont care about extreme accurcy (say player health, or another generalization) use a short or a uchar using the same method at differing magnitude. This will decrease the size of the buffer you are sending to and from the server, increasing performance and decreasing lag.

Also a side note for string and chat message, You can send a 1bye (and 2 byt for chat message) length in front of the string/getmessage, to define the length of the string, so that you can reduce the pull of the string, ex: 0x00001010 "hello my name is chase" so it would pull the uchar len then loop(len)pull a uchar. Then pass that into the string on the client side. This will make the string and messages more efficient (altho in the case of shorter messages it will make it longer, but the trade off is not worth disregarding saying most ppl time long enough sentence/names to make this worth implementing).

Also I HIGHLY SUGGEST IMPLEMENTING XSTRING OR A SIMILAR LIBRARY CUZ CUBESTR IS JUST char [256] which is less efficient (tho super safe).

Yeah i think this is just a pretty early phase of this code, dunno how fast mapc will go for those that all.
However we do not need to worry about any "package as small as possible" ourselves, since our used library protobuf already does that for us (!!) :) +1 for protobuf at this point ^^
Btw @sauers "string" (^^) youre right, we wont use it in future code. But well simply use the stdlibs strings. :)

chasester wrote:

How are you stacking this data though? say:

struct a
   float abc
   float def

struct b
   a hello;
   float def;

how do you place to send across b or would i have to implicedly tell the server i need to:

b::sendserverdata(){ send(float def); send(a->abc); send(a->def); }

or does the code not handle this?

ive no idea, but i'd guess there would just be a main class you need to derive from e.g. "networksyncing"
and every child of it automatically has the properties to automatically sync its members (and all members of member structs ofc).
maybe you'll need some ::changeproperty() function, but lets see how mapc is doing that ^^

Last edited by a_teammate (2015-12-10 02:37:56)

Offline

#29 2015-12-10 06:35:52

chasester
Member

Re: Rival: Cube/tesseract mod

@ bidirectional-property-graph
So you mean a graph based on properties that can move linearly, so a vector of a vector basically. IDK the term seems fairly undefined.

@scenegraph
Scene graph is just a fancy word for a storage of nodes, the structure as of right now is just a vector of nodes, but will probably be changed to either a linked list tree or a vector tree (the difference is basically bidirectionalness).
So the parent will be able to tell if the object as a whole (all the render areas) is visible or not. Allowing to simply work down the tree till that bounds is off the screen and out of a renderable space.
The way the sibling interact will be very different allowing sibling and children to link to eachother based on variables (say vec o, or vec rot, or any other user defined variable). This make it much more powerful.
Then there will be message linking and weak reference linking. So those will be used for weapons and triggers respectively.

@shader
+1 shaders need redone and improved, a lot of speed and performance improvements are done with shaders now-a-days, but cube uses almost none of them. Also imposters would be nice to add :0

@api structure
I have a serializer now (you have no clue how excited I am [pointers -.-]) so basically all the data on the map is serialized on map restart (when you leave editmode). this also allows you to move objects actively in editmode, meaning you can move the rendered object physics objects etc as the game is running, allowing you to test things easier. Ill have an example some time before christmas (hopefully with map loading and saving done).

I think you implementation of the api class is basically the same thing, with the ability to watch the variable as well. If you need help with the api structure when you get to writting it I would love to help.

@source
Ya there is a lot of code that isn't mine under various licences, although it is open source I'm not sure what source dispersion entails and right now there's really nothing to special about it most of it is copy pasted and modified code.

@inexor
Im glad you are not keeping with sauer. Does it have realtime lighting? form the video I saw you are still using lightmaps. Is it a tesseract mod? or is it more from the sauer cube 2 engine?

I posted on your forums a few time I hope you dont mind.

chasester

PS: @hypernova (sorry i ignored this question i must have missed it).
I Don't have a linux unfortunately, Plus I don't have any experience with codeblocks (which i think is the build api) and mingw makes me cringe. Bullet, Angel script, and tesseract (and all other libraries I will add) will/are multiplatform. Towards a alpha release I will look at releasing multiplatform, but mostly at this point spending my time on improving the structure of the engine is more important, saying that the engine isn't even at a usable state as of yet. Moving build environments is fairly hard as it is (even with cmake). SORRIE :(

Last edited by chasester (2015-12-10 06:41:49)

Offline

#30 2015-12-10 23:16:34

Hypernova^
Member

Re: Rival: Cube/tesseract mod

Ah no problem :) As long as I can get a basic bullet implementation in tesseract I will have enough to play around with for a while. This will at least allow me to practice on the networking and other things, even if I can't port to Rival right away. Can't wait for a bullet tutorial x)
-Hypernova

Offline

#31 2015-12-11 22:37:50

chasester
Member

Re: Rival: Cube/tesseract mod

I uploaded the bullet code here. This drops over a current build then you will have to get the includes and lib from bullet (they should have how on their website).
Bullet implimentation is fairly easy though you will have to rewrite the player module (player movement). So that the player can be controlled by the physics. What I suggest making the following changes to the code:

//in ents.h
#include btBulletDynamicsCommon 
// make sure we know what bt objects are just incase we need to use them
...
struct bulletobject;
struct physent                                  // base entity type, can be affected by physics
{
    vec o, vel, falling;                        // origin, velocity
    vec deltapos, newpos;                       // movement interpolation
    float yaw, pitch, roll;
    float maxspeed, weight;                             // cubes per second, 100 for player
    int timeinair;
    float radius, eyeheight, maxheight, aboveeye; // bounding box size

    vec floor;                                  // the normal of floor the dynent is on
    vec resilientvel;                           //velocity we want to keep from last frame
    int inwater;
    bool jumping;
    char move, strafe, crouching;

    uchar physstate;                            // one of PHYS_* above
    uchar state, editstate;                     // one of CS_* above
    uchar type;                                 // one of ENT_* above
    uchar collidetype;                          // one of COLLIDE_* above

    bool blocked;                               // used by physics to signal ai
   btRidgidBody *body; //this will be our interface from cube to bullet

//in the consturctor set the weight to 80 or something.



//in AJPhysics.cpp

void addPhysicEntToBullet(physent *pl)
{
	//player bounding box
	btCollisionShape* colShape = new btCapsuleShape(pl->radius*SCALING, (pl->eyeheight - (pl->aboveeye * 2))*SCALING);
	colShape->setMargin(btScalar(0.04f)); //set this margin larger if object jitters

	//rigidbody is dynamic if and only if mass is non zero, otherwise static
	btScalar mass(pl->weight); //set the mass to pl wieght
	btVector3 localInertia(0, 0, 1); //dont screw with this :P

	colShape->calculateLocalInertia(mass, localInertia);
	btDefaultMotionState* myMotionState = \
                new btDefaultMotionState(btTransform(btQuaternion(0, 0, 0, 1), btVector3(0.0f, 0.0f, 0.0f)));

	btRigidBody::btRigidBodyConstructionInfo rbInfo(mass, myMotionState, colShape, localInertia);
	rbInfo.m_angularSleepingThreshold = btScalar(0.0f);
	rbInfo.m_linearSleepingThreshold = btScalar(0.0f);

	btRigidBody* body = new btRigidBody(rbInfo);

	btTransform startTransform;
	startTransform.setIdentity();

	startTransform.setOrigin(btVector3(player->o.x*0.058825, player->o.z*0.058825, player->o.y*0.058825));

	body->setCenterOfMassTransform(startTransform);
	body->setAngularFactor(btVector3(0, 0, 0)); //dont let the object spin (cuz we will just move the camera
	body->setLinearFactor(btVector3(1, 1, 1)); //but we want to be able to move in all directions
	body->setDamping(0.9, 0.0); //Damping is how much momentum we have from last frame
              // so we keep 10% of the momentum from last frame 
	body->setRestitution(0.0f); //we dont what the body to bounce, cuz its a person not a ball.
	body->forceActivationState(DISABLE_DEACTIVATION); //stops object from sleeping

	body->setWorldTransform(startTransform);
        body->setGravity(btVector3(0.f, 0, 0)); //we are gonna manually handle gravity
	m_dynamicsWorld->addRigidBody(body);
        pl->body = body;
}
//so now we should run the camera, all players(including ai), 
//and monsters. (Basically all objects that move independently.)
//now let make the update code

//first a few helper functions
//some quick conversion functions
inline btVector3 convert2bt(vec vt){ vec v(vt); v.mul(SCALING); return btVector3(v.x, v.z, v.y); }
inline vec convertfrombt(btVector3 &v){ return vec(v.getX(), v.getZ(), v.getY()).mul(SAUER_FACTOR); }

bool rayTest(vec &start, vec &end, vec &normal = vec(0))
{
	btCollisionWorld::ClosestRayResultCallback RayCallback(convert2bt(start), convert2bt(end));
	m_dynamicsWorld->rayTest(convert2bt(start), convert2bt(end), RayCallback);
	if (RayCallback.hasHit()) //we hit something YAY
       {
		end = convertfrombt(RayCallback.m_hitPointWorld); //lets get where the vector hit
		normal = convertfrombt(RayCallback.m_hitNormalWorld); //lets get the normal of that plane
		return true;
	}
	return false;
}

bool canjump(physent *pl) 
{
	if (pl->type != ENT_PLAYER && (pl->state != CS_ALIVE)) return false; 
                  //is the object alive and is the object a player
	vec v(pl->feetpos()); //lets get the players feet so we can see if hes on the ground
	vec n(0); //temp vec
	if (rayTest(vec(v), vec(v).addz(-1.0), n)) //so lets look at our feet and then 1 unit beyond that
        { 
            n.normalize(); 
           //so we want to get a directional vector (look up normalization if you dont know what this is)
            pl->physstate = n.absdot(vec(0, 0, 1.f)) == 1.0f ? PHYS_FLOOR : PHYS_SLOPE; 
                 //ok so what is the angel of what what we are standing on
            pl->floor = n; //ok tell pl the normal of the floor (so we can have fun with it later;
            return true; 
        }
//so now we know if the object is directly below us but what if we are on some weird slope (or in a hole)
	loopi(3) //loop once for the x
        loopk(3)//loop once for the y
        if (rayTest(vec(v), vec(v).add(vec(i - 1, k - 1, -1.5)), n)) 
         //do 1.5 times that length cuz we are looking at an angel
        //so we are gonna look in every -z direction to see if maybe there is an object that we are on.
        {
         pl->physstate = PHYS_SLOPE; //if so we are on a slope
         pl->floor = n; //set the floor
         return true; 
        }
	pl->physstate = PHYS_FALL; //else we must be in the air 0.0 OOOO NO
	return false;
}

//heres where it gets complex 
void btmoveplayer(physent *pl, int curenttime)
{
	int material = lookupmaterial(vec(pl->o.x, pl->o.y, pl->o.z + (3 * pl->aboveeye - pl->eyeheight) / 4));
	bool water = isliquid(material&MATF_VOLUME); //are we in water
	bool floating = pl->type == ENT_PLAYER&&(pl->state == CS_EDITING||pl->state == CS_SPECTATOR);
          //are we in float mode
	float secs = curtime / 1000.f; //get the time so we can do the multiplying correctly
	bool inair = !canjump(pl); //can we jump 0.0
	float jumpheight = 200.f; //we may need to play with this
	pl->jumping = pl->jumping && !inair;
	//floating = true;
        int maxspeed = 500; //make sure that the object isnt moving too fast for bullet.
	vec d (0, 0, 0);
	if (!floating && water) d.mul(0.5f); //add fake water friction
	pl->vel = vec(0); 
        //so we dont want to carry and momentum over from last frame
	vecfromyawpitch(pl->yaw, floating||water||pl->type == ENT_CAMERA ? \
                   pl->pitch : 0, pl->move, pl->strafe, d);
        //get the direction of the camera and store it in d
	d.mul(pl->maxspeed);
	if (pl->state == CS_EDITING){
                
		pl->body->forceActivationState(DISABLE_SIMULATION);//we dont wanna clip on anything
		pl->body->setFriction(0.f);
		pl->body->setDamping(0.0, 0.0);
                pl->body->setLinearVelocity(convert2bt(d*sec*floatspeed*0.01));
		return;
	}
	else if (pl->state == CS_SPECTATOR){
		pl->body->forceActivationState(DISABLE_DEACTIVATION);//we want to clip on everything
		pl->body->setGravity(btVector3(0.f, 0, 0));
                pl->body->setDamping(0.0, 0.0);
                pl->body->setFriction(0.0f);
		pl->body->setLinearVelocity(convert2bt(d*sec));
	}
	else if (game::allowmove(pl)) // is it paused or intermission
        {
                pl->body->forceActivationState(DISABLE_DEACTIVATION); //stop the player from deactivation
                pl->body->setDamping(0.9, 0.0); 
                pl->body->setFriction(pl->physstate == PHYS_FALL ? 0.1\ //if we are falling add air friction
                 : pl->physstate == PHYS_SLOPE&&(!pl->move && !pl->strife) ?0.4f\  
                 \   //are we on a slope and we are not moving
                 : 0.2f); //if we are on a slope moving, or on the ground then we need to set normal friction
		if (pl->physstate == PHYS_FALL)
                {
                        pl->body->setDamping(0.3, 0.0); //we want less damping when we are in the air
			d.mul(0.2f); //we want to stop the player from moving as fair
			
			if (pl->timeinair > 2000)pl->timeinair = 2000;
                          //cap your make speed from gravity so we dont fall through the map
			if (pl->timeinair > 100) 
                              g = vec(0.f, -pow(30.48f, pl->timeinair*0.001), 0); //handle gravity
			pl->timeinair += curtime;//add to the timeinair
		}
		else{ pl->timeinair = 0; }
		if (pl->jumping){
			pl->jumping = false;
			d.addz(jumpheight);
			game::physicstrigger(pl, true, 1, 0);
		}
                d.add(pl->resilientvel*sec); //apply the left over velocity
                pl->reliantvel.mul(0.2/sec); //decay over time
                loopi(3)clamp(-maxspeed, d[i], maxspeed); //make sure that no direction is moving too fast
		pl->body->setLinearImpulse(convert2bt(d.mul(secs), btVector3(0, 0, 0)); //set the velocity
                //NOTE: never call applyLinearImpulse because this will be ignored, rather set resilientvel
                // in the case of a jumppad pl->resilientvel = vec(attr1, attr2, attr3);
	}

}

chasester

PS: I tried to make this as readable as possible but the wordwrap sucks :(
PSS: All the code above was hardly deskcheked, so theyre probably are errors. This should replace the current functions of the same name in the respective files.
PPSS: If you need any help with the code Just ask (or if you get some kinda strange errors).

Last edited by chasester (2015-12-11 22:52:31)

Offline

#32 2015-12-11 23:11:07

Hypernova^
Member

Re: Rival: Cube/tesseract mod

Thanks, this was exactly what I wanted x)))

Offline

#33 2015-12-12 20:55:47

spikeymikey0196
Member

Re: Rival: Cube/tesseract mod

I hate to be "that" guy who tells someone to add something to someones work.. but for the love of all things holy, please add physically based rendering :3
https://www.marmoset.co/toolbag/learn/pbr-theory <-- found that resource, not sure what resources would be useful for said subject entirely

Offline

#34 2015-12-12 22:51:51

Lord Kv
Member

Re: Rival: Cube/tesseract mod

spikeymikey0196 wrote:

I hate to be "that" guy who tells someone to add something to someones work.. but for the love of all things holy, please add physically based rendering :3
https://www.marmoset.co/toolbag/learn/pbr-theory <-- found that resource, not sure what resources would be useful for said subject entirely

I've already experimented with PBR in my own project (unrelated to tesseract) and some day I may try to add it to tesseract. See the posts on page 1 of this node.

chasester wrote:

@shader
+1 shaders need redone and improved, a lot of speed and performance improvements are done with shaders now-a-days, but cube uses almost none of them. Also imposters would be nice to add :0

Not really. If someone can improve them performance-wise, it's not me. LOD system would help a lot more.

Offline

#35 2015-12-18 22:57:46

a_teammate
Member

Re: Rival: Cube/tesseract mod

chasester wrote:

So the parent will be able to tell if the object as a whole (all the render areas) is visible or not. Allowing to simply work down the tree till that bounds is off the screen and out of a renderable space.

Yeah well i guess thats what Hanack meant with that the hierarchical approach is less performance critical.
Sidenote: You should prepare for instances where e.g. your entity is off-screen but its childrens are not (e.g. a particle system having an emitter offscreen but the particles are visible)

chasester wrote:

I think you implementation of the api class is basically the same thing, with the ability to watch the variable as well. If you need help with the api structure when you get to writting it I would love to help.

@source
Ya there is a lot of code that isn't mine under various licences, although it is open source I'm not sure what source dispersion entails and right now there's really nothing to special about it most of it is copy pasted and modified code.

@inexor
Im glad you are not keeping with sauer. Does it have realtime lighting? form the video I saw you are still using lightmaps. Is it a tesseract mod? or is it more from the sauer cube 2 engine?

I posted on your forums a few time I hope you dont mind.

Nah, really thats great! We really appreciate input!

@lighting We are a community fork of sauerbraten actually. But yes, we will sooner or later have to merge the deffered lighting system (since we want dynamic maps). The only part we have different opinions about is how soon or late that is, my opinion is that it has low priority currently ^^.

Help is always strongly needed of course :) (mapc and Fohlen are currently working on the tree api on node.js and c++ side, but since its a lot to do there ..)
Would be cool if you just hop into our irc channel for communication purpose
(i didnt intend to highjack your topic here ^^)

@source
That seems like a valid reason, since a lot of companies have long cleaning session before releasing their source. Its just more likely that people can improve your work if you show it :P

@bullet-code
At this point: nice that you document your work! ++1

@shader system
I just wrote a basic draft of how i imagine the shader system to look like,
plz edit or write suggestions or just use it as draft for rival:
https://github.com/inexor-game/code/wiki/Shader-System
(ping Lord Kv, chase, everyone else, edit it if its incorrect or u got ideas for improvments, thats why its a wiki)

Offline

#36 2015-12-19 03:48:42

chasester
Member

Re: Rival: Cube/tesseract mod

a_teammate wrote:
chasester wrote:

So the parent will be able to tell if the object as a whole (all the render areas) is visible or not. Allowing to simply work down the tree till that bounds is off the screen and out of a renderable space.

Yeah well i guess thats what Hanack meant with that the hierarchical approach is less performance critical.
Sidenote: You should prepare for instances where e.g. your entity is off-screen but its childrens are not (e.g. a particle system having an emitter offscreen but the particles are visible)

An emiter has no point of keeping its children. 99% of particles are fire and forget leting it control itself. In the rare case where you may want to do something to all the particles of a particles emiter (and not just of a certain type) you would store them as weakref<particleclass> children. This would make it so that you could go and modify attributes of the emitted nodes without needing to worry about things like render spaces.

What a render tree and why you would use it, is for things like player entities (or monster ect). They have more than just one element ie playermodel, gunmodel, atttachments, particles (maybe displaying name)). With multiple controlers, ie animator, weapon logic, movement logic, physics, model info, etc

In that case where you can divide a complex object into multiple parts, you can simply reject the parent (which would have the bounds of all of its children contained inside it. Normally you do this with a sphere, and then aabb detection, so you can speed up rejection culling.

The point of a tree structure is:

  • That every node has a bounds, and a max radius

  • And that the parents bounds encapsulates all of its children.

Otherwise a tree struct is about pointless, you might as well just store it in a node.

@IRC
Ppl still use that? Probably would have no clue how to or what to use it on. Besides I find post allow me to come up with more fuller ideas.

@Source
Ya true there is always room for improvemnt :)

@Documentation
Ya I hate cube in that I keep finding out new commands I never knew existed that have been in there forever. The config ref is a joke, and the wiki is equal parts confusing, and outdated. So I very much like documenting things.

@shader system
Its a good concept. Nothing really unique. But simple would be a major improvement.

@lighting
I read your response on your forum. Its a good idea, to improve performance.

Offline

#37 2015-12-24 22:57:02

Hypernova^
Member

Re: Rival: Cube/tesseract mod

Hey Chasester,

   I have a few strange errors, I'm not sure what was intended in some of these:

   

engine/AJMPhys.cpp:348:56: error: could not convert ‘vec(0)’ from ‘vec’ to ‘vec&’
 bool rayTest(vec &start, vec &end, vec &normal = vec(0))
                                                        ^
engine/AJMPhys.cpp: In function ‘bool canjump(physent*)’:
engine/AJMPhys.cpp:368:45: error: invalid initialization of non-const reference of type ‘vec&’ from an rvalue of type ‘vec’
     if (rayTest(vec(v), vec(v).addz(-1.0), n)) //so lets look at our feet and then 1 unit beyond that
                                             ^
engine/AJMPhys.cpp:348:6: error: in passing argument 1 of ‘bool rayTest(vec&, vec&, vec&)’
 bool rayTest(vec &start, vec &end, vec &normal = vec(0))
      ^
engine/AJMPhys.cpp:380:67: error: invalid initialization of non-const reference of type ‘vec&’ from an rvalue of type ‘vec’
         if (rayTest(vec(v), vec(v).add(vec(i - 1, k - 1, -1.5)), n))
                                                                   ^
engine/AJMPhys.cpp:348:6: error: in passing argument 1 of ‘bool rayTest(vec&, vec&, vec&)’
 bool rayTest(vec &start, vec &end, vec &normal = vec(0))
      ^
engine/AJMPhys.cpp: In function ‘void btmoveplayer(physent*, int)’:
engine/AJMPhys.cpp:419:57: error: no match for ‘operator*’ (operand types are ‘vec’ and ‘float’)
                 pl->body->setLinearVelocity(convert2bt(d*secs*floatspeed*0.01));
                                                         ^
engine/AJMPhys.cpp:419:57: note: candidates are:
In file included from shared/../bullet/src/BulletCollision/CollisionDispatch/btCollisionWorld.h:80:0,
                 from shared/../bullet/src/btBulletCollisionCommon.h:22,
                 from shared/../bullet/src/btBulletDynamicsCommon.h:20,
                 from shared/ents.h:5,
                 from shared/cube.h:64:
bullet/src/LinearMath/btVector3.h:769:1: note: btVector3 operator*(const btVector3&, const btVector3&)
 operator*(const btVector3& v1, const btVector3& v2) 
 ^
bullet/src/LinearMath/btVector3.h:769:1: note:   no known conversion for argument 1 from ‘vec’ to ‘const btVector3&’
   

Can you give me any hints?

Offline

#38 2015-12-25 03:38:51

chasester
Member

Re: Rival: Cube/tesseract mod

@1-3
should be:
bool rayTest(vec &start, vec &end, vec &normal = new vec(0)); //pointers -.-
or probably better to just make it:
bool rayTest(vec &start, vec &end, vec &normal); //and force the normal

@4
you dont have *operator set up in your vector i suggest setting up all the operators using a macro
but for now
pl->body->setLinearVelocity(convert2bt(vec(d).mul(secs*floatspeed*0.01)));

//define this at the top of the geom.h file
#define TEMPOPERATOR(c, o, op, func) template<class T> c operator##op (T a){ return o.##func(a); }
...
struct vec
{
...
//define this inside the vec struct
	TEMPOPERATOR(vec, (*this), += , add);
	TEMPOPERATOR(vec, (*this), -= , sub);
	TEMPOPERATOR(vec, (*this), *= , mul);
	TEMPOPERATOR(vec, (*this), /= , div);
	TEMPOPERATOR(vec, (vec(*this)), +, add);
	TEMPOPERATOR(vec, (vec(*this)), -, sub);
	TEMPOPERATOR(vec, (vec(*this)), *, mul);
	TEMPOPERATOR(vec, (vec(*this)), / , div);
...
}

I highly suggest doing this for all of your geom classes (vec, vec2, vec4, quat, plane, and your matrixes);

@5-6
is caused by 4. Make sure that you have the convert2bt() set up correctly I assume the compiler through an error cuz of the *operator so it should be solved but it should return a btvector3.

Hopefully that works
chasester

Ps Remember that all your object need to be bottom aligned (in the modeler) otherwise it will render incorrectly. I suggest making an mdl option MDLCENTERALIGNED to tell the model how it should be rendered and do the centering inside the rendermodel().

Last edited by chasester (2015-12-25 03:42:29)

Offline

#39 2015-12-25 17:31:55

Hypernova^
Member

Re: Rival: Cube/tesseract mod

Hey Chase,

Thanks for the reply. I changed the rayTest definition, but I still get this:

engine/AJMPhys.cpp:368:45: error: invalid initialization of non-const reference of type ‘vec&’ from an rvalue of type ‘vec’
     if (rayTest(vec(v), vec(v).addz(-1.0), n)) //so lets look at our feet and then 1 unit beyond that
                                             ^
engine/AJMPhys.cpp:348:6: error: in passing argument 1 of ‘bool rayTest(vec&, vec&, vec&)’
 bool rayTest(vec &start, vec &end, vec &normal)
      ^

Good idea on the TEMPOPERATOR macro, btw you don't need ## for operator because the result is not really a single token. 

Ps. Ah this is a good point, but what do you mean by 'bottom aligned'? Sorry I'm a noob at 3d modeling x)

Offline

#40 2015-12-25 19:30:14

chasester
Member

Re: Rival: Cube/tesseract mod

@##
I thought it was :) but good to know

@code
bool rayTest(const vec &start, const vec &end, const vec &normal);
that should work, idk why it needs them to be constants, but that's what the error message is telling you to do :) so listen to it :)

Im not sure why your compiler is being picky about that, which compiler are you using?

if that doesnt work then do
bool rayTest(vec start, vec end, const vec &normal);
cuz thats actually the way it should be you dont need to reference your start and end paramaters cuz you arent actually gonna use them for anything afterward saying your are passing them with vec( ) wrappers.

@bottom aligned
0,0,0 is at the bottom center of the object
rather than the center of the object

All objects in tesseract except the ball (index 1) are bottom aligned, the ball is center aligned.

chasester

Offline

#41 2015-12-26 14:48:35

Hypernova^
Member

Re: Rival: Cube/tesseract mod

Hi Chase,

   @rayTest()
   
     I'm using the g++ compiler, I know it can be picky at times :) I should have known the references to start and end were not needed, thx for pointing that out.

   @bottom aligned

   Ah thx for the explanation.

   I have some other questions if you don't mind xD

if (pl->timeinair > 2000)pl->timeinair = 2000;
//cap your make speed from gravity so we dont fall through the map
if (pl->timeinair > 100)
     g = vec(0.f, -pow(30.48f, pl->timeinair*0.001), 0); //handle gravity
     ^
pl->timeinair += curtime;//add to the timeinair

  The variable 'g' is not declared and is not used before it goes out of scope. Should there be a call here or something?

  One more thing :)

loopi(3)clamp(-maxspeed, d[i], maxspeed); //make sure that no direction is moving too fast
pl->body->setLinearImpulse(convert2bt(d.mul(secs)), btVector3(0, 0, 0)); //set the velocity
                                            ^
//NOTE: never call applyLinearImpulse because this will be ignored, rather set resilientvel
// in the case of a jumppad pl->resilientvel = vec(attr1, attr2, attr3);

   btRigidBody has no member called setLinearImpulse, should this be something else?
   Sorry for my noobness I don't know much about how bullet works xD but I am learning...

   Thx very much for the help, I really appreciate it :)

Last edited by Hypernova^ (2015-12-26 14:51:35)

Offline

#42 2015-12-27 04:34:38

chasester
Member

Re: Rival: Cube/tesseract mod

@g
g is gravity :p so just add it to the overall velocity, sorrie some of the code is stuff i had written and some was shit i was writting on the fly.

@btRIgidBody
This is why vsc++ is awesome cuz it lets you see all the members of any token :)
inline void setLinearVelocity(const btVector3& lin_vel);
so its velocity not impulse ;p lol its applylinnearimpulse(); sorrie

chasester

Offline

#43 2015-12-27 15:18:34

Hypernova^
Member

Re: Rival: Cube/tesseract mod

lol no problem, thanks for clearing that up :)

btw when I've finally got bullet working I'm thinking of posting the whole modified Tesseract source so others won't have to figure it all out. Is that ok with you?
Thanks

Offline

#44 2015-12-28 00:51:32

chasester
Member

Re: Rival: Cube/tesseract mod

most of it is Anglo code and he posted it free so ya I think if have like 3 functions and like 10 lines of modification :
my code is fine
angelo code is fine
bullet is obviously fine

so sure :)
But first i would make a few modifications so its not so confusing.

Add a new enum element

//iengine.h ln 425 ish
enum { MDL_CULL_VFC = 1<<0, MDL_CULL_DIST = 1<<1, MDL_CULL_OCCLUDED = 1<<2, MDL_CULL_QUERY = 1<<3, MDL_FULLBRIGHT = 1<<4, MDL_NORENDER = 1<<5, MDL_MAPMODEL = 1<<6, MDL_NOBATCH = 1<<7, MDL_ONLYSHADOW = 1<<8, /*add this*/MDL_CENTER_ALIGNED = 1<<9 /*end here */ };

Then in rendermapmodel()

//rendermodel.cpp ln 944 ish
void rendermapmodel(int idx, int anim, const vec &o, float yaw, float pitch, float roll, int flags, int basetime, float size)
{
...
    m->boundbox(center,bbradius);
//start here
     if (flags&MDL_CENTER_ALIGNED){
		vec pos = vec (0, 0, -1);
		yaw -= 90;
		if (roll)pos.rotate_around_y(-roll*RAD);
		if (pitch) pos.rotate_around_x(pitch*RAD);
		if (yaw)pos.rotate_around_z(yaw*RAD);

		pos.mul(bbradius.z);
                o.add(pos);
	} //end here
...
}

This will center on command basically so then when you are rendering a bullet ent do.

  rendermapmodel(index, 0, o, yaw, pitch, roll, MDL_CULL_VFC | MDL_CULL_DIST|MDL_CENTER_ALIGNED, 0, scale);

Then lastly do a stright call in update movables:

//in AJMovables.cpp ln 160 ish
void updatebulletmovables(vec tmpvec, vec tmprot, int j)
{
...
    m->yaw = tmprot.z ; // take off the -90; cuz you are doing this when you render :)
    m->pitch = tmprot.y; 
    m->roll = tmprot.x;
...
}
//ln 202 ish
void renderbulletmovables()
{
      bulletmovable &m = *bulletmovables[i];
   // if(m.state!=CS_ALIVE) continue;
   //vec o = m.feetpos();//o must be center of model
   //vec pos(0, 0, 1);
   //if(m.roll)pos.rotate_around_y(-m.roll*RAD);
   //if (m.pitch) pos.rotate_around_x(m.pitch*RAD);
   //if (m.yaw)pos.rotate_around_z(m.yaw*RAD);
    //pos.mul(-m.radius.z);
    //pos.add(m.o);
    //particle_flare(pos.add(m.o),m.o , 0, PART_STREAK, 0x0000FF);
//remove all the commented code;
...
}

this hides it from the user so it doesnt look weird :) and allows you to switch between center align and bottom aligned models. You could just go into model.h and rewrite stuff to move the model loading so it only takes positive z values :) so everything is always bottom aligned :) or better set a cube script command mdlalignmodel (int) and let people set this to what every alignedness they want and then just convert it :) that way if you have a model inswitch you want off center from the physics box, it can be ;) (or they could just use mdlaabbsize (i think thats the name of the command).

any way that should make it cleaner.

I would upload that code but my computer is super slow so it took me like 20 mins to upload those 2 files idky the upload speed is so fucked up :) originally i wanted to with the lib files and the vcpp files.

Any way thanx
chasester

PS: Again this is all sudo code, taking from my current project sorrie if i missed something :) But i think you get the general concept :)

PSS: I would set up a movables struct that is not inheriant of physicsent because its super bulky

struct bulletmovable {
	int etype, mapmodel, weight;
	float yaw, pitch, roll;
	vec o, radius;
	btRigidBody* body;
	bulletmovable(const entity &e) : 
		etype(e.type), mapmodel(e.attr1),
		yaw(e.attr2), pitch(e.attr3), roll(e.attr4), 
		o(e.o), weight(e.attr5)
	{
		const char *mdlname = mapmodelname(e.attr1);
		if (!mdlname) return;
		model *m = loadmodel(mdlname);
		if (!m) return;
		vec center, bbradius;
		m->boundbox(center, bbradius);
		radius = bbradius;
			
	}
};

thats how i set up mine
notice i didnt use scale rather weight. I feel thats more important, if you want a smaller scale maybe just create a new model file with the new size you want :) a lot of engines dont do scale on physics ents. Just model only objects :) 0  or less is infinite weight

Last edited by chasester (2015-12-28 01:01:20)

Offline

#45 2015-12-28 18:06:27

Hypernova^
Member

Re: Rival: Cube/tesseract mod

Wow thanks for all the code... I'll definitely use it :)

Last edited by Hypernova^ (2015-12-28 18:12:46)

Offline

#46 2016-01-14 11:27:24

chasester
Member

Re: Rival: Cube/tesseract mod

We are looking at the next release of Rival to be on the 26 of Jan. Due to the holidays I was not able to come up with a release video for the 3rd release (all it really included was moving nodes, and saving/loading from the map file).  The Jan 26 release will be both release three and four, (or the Thor release). This will be as usual, video on the 26, zip (with exe, and as files) the the day after. Release 5 will be mostly feature requests and cleaning up both bullet physics and the level build, code. The Thor release will be the first game development release meaning there should be enough functionality in the as code interface to allow for game development to start. So if your game needs access to particular functionality post here or email me @ chasester123@gmail.com. I will do my best (based on the complexity of the request) to add it into the build, and send a new exe with the feature request.

I'm Extremely Excited to show what I've been working on :)
chasester

Offline

#47 2016-01-15 03:42:57

Hypernova^
Member

Re: Rival: Cube/tesseract mod

That's awesome, can't wait to see it :) But still no linux binaries? :D

ps: I'm got close to finishing my bullet implementation in Tesseract but I have linking errors which I can't figure out, building with Makefile. Is this something you could help me with?

Last edited by Hypernova^ (2016-01-15 03:43:22)

Offline

#48 2016-01-15 18:05:35

chasester
Member

Re: Rival: Cube/tesseract mod

make sure you have the lastest version of cmake (or what ever your using), I Hate cmake and know about nothing about it. So I dont think i would be much help. If its bullets cmake files maybe post on their forum they may know what you are doing wrong.

Offline

#49 2016-01-16 00:56:17

Hypernova^
Member

Re: Rival: Cube/tesseract mod

Ok got it xD

I have a question about your AS interface: Will the user be able to create new particle systems? Or modify the behavior algorithms of the existing ones?

Last edited by Hypernova^ (2016-01-16 16:28:28)

Offline

#50 2016-01-20 16:19:37

chasester
Member

Re: Rival: Cube/tesseract mod

both
There will be defaults (like texture or map models) but you will be able to registrar new textures (the image), behavior (like gray scale, full color etc), and also the motions (how it moves, velocity, physics collision etc). So basically one will be created from one of each of the options. These options will have to be registered in the config. This is similar to what it does in the source I will just convert this into as code basically. (I maybe using an outside library for particles, I'm not sure as of yet.) I havent dived to much into the particle source code, but from tinkering with it before, all the presets are just preset options, and you could have a lot more dynamic particles by simply just opening things like o, vel, rot, etc up to the user to change on a per update. This is probably what I will start with then move to something more advance later.

Is there a particular thing you would like to do with the particles?

chasester

Offline

Board footer