rotating mesh, how?

Questions and answers about the how and why of making maps.
z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

rotating mesh, how?

Post by z[h]ero » Tue Sep 04, 2007 7:39 pm

Hi,

how to do rotating meshes?
I readed the bzw-documentation, this documentation is just a joke, if u want to find out how to make meshes rotating.
The wiki is better, but still there misses many many information how to do it. After i fighted much over 1 hour (maybe i spended much more time) reading about it in the bz-forum and trying to code it i then just did give up.

If i have a mesh having this typical structure, how do i make it rotating in an easy way?

Code: Select all

mesh
	name aMesh
	vertex ...
	normal ..
	matref bla
	face 
		vertices ...
		normals ...
	endface
end #end mesh
First i tried it like that, i added the drawInfo-section:

Code: Select all

mesh
	name aMesh
	vertex ...
	normal ..
	drawInfo 
		angvel 60 #should rotate 60 times in a minute
		matref ...
	end # drawInfo
	face 
		vertices ...
		normals ...
	endface
end #end mesh
After reading in the bzforum i found out it can't be done so easy.
(Why the hell was bzflag coded like this that a simply rotation command inside the mesh isn't enough to make the mesh rotating? Technically a simple rotation command could be sufficient, cause the cpu would "simply" always calculate the new rotated coordinates of the vertices and normals of the mesh, thats all, cause openGl anyway does the 3d rasterisation. But instead doing this way, the users seems to need to generate a tripstrip or quadstrip and needs to code even more infos?)
What are the minimum infos that are needed inside the drawInfo to make a mesh rotating? I don't want to have unnecessary overhead.

Oh btw i don't know anything about:
lod, dlist, tristrip, quadstrip, ... I just know some few basics. I hope its not needed to know about it? Else i would be glad for a short and easy explanation.

Does the mesh needs first to be transformed into a quadstrip or a tristrip? If yes, how to do it? What else needs to be done step by step?
Isn't there an easy way to make any mesh a rotating mesh?
Last edited by z[h]ero on Wed Sep 05, 2007 5:15 pm, edited 2 times in total.
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."

User avatar
blast
General
General
Posts: 4749
Joined: Fri Mar 21, 2003 3:49 pm
Location: playing.cxx
Contact:

Post by blast » Tue Sep 04, 2007 8:02 pm

One thing to keep in mind is that objects that are animated with drawInfo will be decoration only, meaning they will not be collision objects. Tanks and bullets will pass though them.

As for how to make them, someone else will have to help with that.
"In addition to knowing the secrets of the Universe, I can assure you that I am also quite potty trained." -Koenma (Yu Yu Hakusho)

Image

z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

Post by z[h]ero » Tue Sep 04, 2007 8:10 pm

blast wrote:objects that are animated with drawInfo will be decoration only, meaning they will not be collision objects. Tanks and bullets will pass though them.
Tks, i know.
Someone even did write that OO tanks crash if they drive trough such rotating objects, anyway, i still am interested in rotating meshes.
Edit: "Optical delusion" told now, only BAD MADE drawInfo makes OO-tanks crashing.

I forgot to say, rotation around the z axis would be sufficient.
But if someone knows how rotation around other axis work, then just tell it.
Last edited by z[h]ero on Thu Sep 06, 2007 12:24 pm, edited 1 time in total.
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."

User avatar
Macrosoft
Private First Class
Private First Class
Posts: 142
Joined: Fri May 04, 2007 2:21 am

Post by Macrosoft » Wed Sep 05, 2007 1:10 pm

z[h]ero: angvel 60 would make it rotate 60 times per second, not minute.
its angvel rotations/second
gazz: A bullet may have your name on it, but shrapnel is addressed "to whom it may concern".
http://bash.org/?785529

User avatar
Tedius
Sergeant First Class
Sergeant First Class
Posts: 142
Joined: Tue Sep 19, 2006 6:10 pm
Contact:

Post by Tedius » Wed Sep 05, 2007 2:19 pm

z[h]ero,
before delving too much further into the world of drawinfo, are you sure it is what you are looking for?

If it is a flat face that you want spun, a texture matrix applied to the face will do the trick:

Code: Select all

textureMatrix
name example_texmat
spin 0.0 # rotation freq
center 0.5 0.5 # dynamic u/v center (for spin and scale)
end
If you want tanks to be rotated along with it, like on Louman's Roundabout, you would use physics thusly:

Code: Select all

physics 
   name spin 
    angular 0.05000 0.0 0.0 #rotates .05 times a second about the center point of the map
end
If you want an object of many faces to be rotated together that doesn't affect gameplay, drawinfo is your answer.

Sources:
My favorite manpage: http://linux.die.net/man/5/bzw
Discussion about my whirlpool http://my.bzflag.org/bb/viewtopic.php?t=10902
wiki: http://my.bzflag.org/w/Physics

EDIT: Oh yeah, one more link regarding drawinfo: http://www.garrettsites.net/bzmaps/inde ... ail&id=212
this signature intentionally left blank

z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

Post by z[h]ero » Wed Sep 05, 2007 3:43 pm

z[h]ero: angvel 60 would make it rotate 60 times per second, not minute.
Hmm true, thats written in the bzw-docu.
I thought its per minute, cause i had analysed an exapmle with "angvel 50". It seemed to rotate about 1 time per second. Now i checked out exactly, it rotates 1 time in 7.5 seconds! Weird! (Dont tell me now that i have a very bad sense of time, with an impressiv bad factor of 7.5 :P )
If you want an object of many faces to be rotated together that doesn't affect gameplay, drawinfo is your answer.
Exactly this is what i am searching for.
EDIT: Oh yeah, one more link regarding drawinfo: http://www.garrettsites.net/bzmaps/inde ... ail&id=212
Tks. (Btw, really impressive artistic and eye candy rotating things the man presented there, something like that doesn't exist on any of the bz-list-servers, worth to be checked out folks!)
But the problem is, i somewhere did find a much more easy rotating example, it was just a rotating pyramid, i tried to analyse the DrawInfo code, but it was still too complicated.

I think this was the drawInfo, and i don't understand anything here:

Code: Select all

drawInfo 
dlist 
	# extents -1 -1 0 1 1 1 
	# sphere 0 0 0.5 2.25 
angvel 50 
corner 0 0 0 
corner 1 1 1 
corner 2 2 2 
corner 3 3 3 
corner 4 4 4 

lod # 0 
lengthPerPixel 0 
matref -1 
dlist 
tristrip 0 1 4 2 4 3 0 2 1 

	#tristrip 2 3 4 0 1 3 2 4 
	#tristrip 0 1 3 2 4 1 
end # material -1 
end # lod 0 

end # drawInfo 
More infos, i have a pretty long bzw-transformed-mesh.
And i found out, the code that needs to be added inside the DrawInfo depends on the mesh. (And i can't handcode mesh, so i would need an easy solution for my complicated mesh).
So still i dont know what needs to be done step by step? :/
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5182
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Wed Sep 05, 2007 4:00 pm

There is no easy solution, draw info was never fully completed by it's author before he quit working on BZFlag. You will have to hand code the draw info for each mesh. You will have to do math for each object. There is no editor, there is no tool, it's all you.

I also doubt anyone here is familiar enough with draw info to give you a "Step by step" you will have to do a lot of the research yourself.

z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

Post by z[h]ero » Wed Sep 05, 2007 5:43 pm

JeffM wrote:There is no easy solution, draw info was never fully completed by it's author before he quit working on BZFlag. You will have to hand code the draw info for each mesh. You will have to do math for each object. There is no editor, there is no tool, it's all you.
I also doubt anyone here is familiar enough with draw info to give you a "Step by step" you will have to do a lot of the research yourself.
Omg, this is bad!
If there is no easy way, i would be ready to try math and to do a bit hand-code, if someone knows how to do it and has the time to explain it, how it needs to be done for a complicated mesh.
If this stuff can be done with the help of a good explanation in less then 20-(max.45min) for complicated meshes then i still wanna know. Else i am not interested, cause i would need then maybe some hours and it maybe anyway would not work. But in this case i guess other people would be still glad to read how to do it.
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5182
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Wed Sep 05, 2007 6:31 pm

your god has little to do with it.

As I said, few know about it, other then it's author. and those that do are not experts, but have simply fuddled around and figured out bits and pieces.

It's not a feature that even the developers know much about, hence why we don't go saying much about it. The author took most of the information on that code with him.

So it's up to you to figure it out, you'll probably have to look at the code to do it too.

z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

Post by z[h]ero » Wed Sep 05, 2007 7:39 pm

omg, so the situation is even more bad!
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."

User avatar
Winny
Grouchy
Grouchy
Posts: 2381
Joined: Wed Aug 24, 2005 12:27 am
Location: Ottawa eh?
Contact:

Post by Winny » Wed Sep 05, 2007 8:24 pm

z[h]ero wrote:omg, so the situation is even more bad!
No need to play it up, you sound like your starring in some soap-opera.


Personally, I see no need for drawinfo, since it cannot effect the tanks in any way, and therefore proves more or less meaningless on the map.

If I were you, I'd spend more time on the map itself, and less on the eye-candy.

User avatar
Teppic
Private First Class
Private First Class
Posts: 575
Joined: Mon Mar 07, 2005 10:00 pm
Location: The North Block
Contact:

Post by Teppic » Wed Sep 05, 2007 8:46 pm

z[h]ero, if you do enough research to be able to explain to me how it works, I'll write the script to animate static meshes for you.

EDIT: OK, I looked at the complicated example, someone explain WTF tristrip and tris mean we should be good to go.....

User avatar
joevano
General
General
Posts: 1863
Joined: Sat Jun 18, 2005 1:08 pm
Location: South Bend, Indiana, USA

Post by joevano » Wed Sep 05, 2007 8:52 pm

I found this to be pretty helpful explaining the concept of a tristrip http://www.cs.queensu.ca/home/jstewart/ ... algorithm/
There is nothing worse than aggressive stupidity. -- Johann Wolfgang von Goethe
"How many legs does a dog have if you call his tail a leg? Four. Calling a tail a leg doesn't make it a leg." -- Abraham Lincoln

z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

Post by z[h]ero » Wed Sep 05, 2007 9:13 pm

Everything here off-topic, no need to read:
If I were you, I'd spend more time on the map itself, and less on the eye-candy.
Don't worry, if u would know me, u would know that gameplay always had and always will have more priority for me than eye-candy features.
That's one reason why i prefer normally more the simple maps with nice gameplay instead of the eye-candy ones.

Personally, I see no need for drawinfo, since it cannot effect the tanks in any way, and therefore proves more or less meaningless on the map.
True, i see no need for drawInfo,too.
As i am a (very) conservative bzplayer, i see even no need for many other things. For example i see in kinda all cases no need to texture every box and every mesh. Its even more worse then "no need", there are not just some few player that can't afford to activate textures. So for these people such maps are kinda unplayable.
But anyway, i wanna have the right to try out meaningless things :) And i will make use of this right. (I know, u did not forbid me to make use of this right) And if bz will have new feature, i will try it out if i am in such mood, even if its meaningless.
Well, i could make a much more longer essay, but i think i shall stop talking about it, its anyway off-topic. But u are welcome to discuss it with me personally.


Btw, thanks god that rotating meshes arn't completely easy deasy, if this would be the case, lots of bz-kiddies would make massiv usage of this, the servers would be then so much messed up.
Last edited by z[h]ero on Wed Sep 05, 2007 10:00 pm, edited 2 times in total.
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."

User avatar
Spazzy McGee
Sergeant Major
Sergeant Major
Posts: 1403
Joined: Mon Mar 21, 2005 4:59 pm
Location: Planet MoFo, Sheffield Division; United Kingdom
Contact:

Post by Spazzy McGee » Wed Sep 05, 2007 9:34 pm

Knowing what all the different components are and plugging in values is the easy bit - when it gets tricky is trying to figure out the order of corners in, say, a tristripm, which is basically a long line of linked triangles, arranged in a strip. see donny's link. (note: If you can't understand the first couple of paragraphs, going further into the drawinfo is not for you.)

For any kind of complex object this is going to be near impossible, considering no body (except trepan) knows how to order corners in a drawinfo mesh correctly - only through trial and error have others managed it. What is required is some form of "stripifier" - a program that can calculate where the tristrips (or indeed quadstrips) need to be put for a complicated mesh. Apparently trepan wrote one, but has since 'lost' it, and nobody is expecting him to re-write it. Once somebody works out the best was to construct these strips quickly and efficiently from standard mesh code, we can possibly make some headway in actually making a stripifier. But that's a long way off.
"Life is what happens to you while you're busy making other plans." - John Lennon

User avatar
Teppic
Private First Class
Private First Class
Posts: 575
Joined: Mon Mar 07, 2005 10:00 pm
Location: The North Block
Contact:

Post by Teppic » Wed Sep 05, 2007 10:25 pm

Spazzy Mcgee wrote:Once somebody works out the best was to construct these strips quickly and efficiently from standard mesh code, we can possibly make some headway in actually making a stripifier.
That seems to be the way forward.

So, I'm looking for clarification of what I have understood,

Tristip, strip of 3 vert polys
Quadstrip, strip of 4 vert polys
Trifan, kinda like a hexagon effect, fan being the operative word, 3 vert polys with common vert
Tris, those that didn't fit above

Assuming this is correct, I'm not gonna do this more than once, so algorithm looks thusly:

Identify Quadstrips, create output (hmm???), remove from analysis mesh
Identify Tristrips, create output (hmm???), remove from analysis mesh
Identify Trifans, remove from .....
Lastly stick in the left over tris.

Anyone see a problem with this? Other than no one knows the order of the verts in the strip definitions?
EDIT:OK, I worked out the second bit....
I will go ahead and read this guys huge PDF if some people volunteer to mathematically error check the 'stripifier' before I start coding.
Well, I'm just thinking out loud, but someone may have allready done this over at the Blender forums, in which case is a plug in for blender OK, or do we want a .bzw coded mesh transformed from traditional style to drawinfo via a C++ compiled app?

It's a difficult choice, I can see lots of the work is allready done if I use blender, but python may be slow for this, C++ will be much faster on the math, but it will also have to do so much more......
I think blender with a python wrapper round a C++ analysis tool would be quickest, but, OMG newbie hell, learn blender and how to compile source code......

anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly » Wed Sep 05, 2007 10:47 pm

For what it's worth, this is from one of trepan's posts (he is the author of drawinfo)

Code: Select all

drawInfo blocks are used to pipe information to the
client that can be used with glDrawElements(), and
that can be organized to increase the rendering
efficiency (read: triangle strips). They also contain
information that can be used to build Levels of Detail
(LODs). LODs draw fewer elements for an object if
it is further away.

In addition to those features, I've also added the
ability to dynamically rotate the elements within a
drawInfo about the Z axis at the origin. The dynamic
rotation is performed before any object transformations.

DrawInfo corners relate to the elements sent to a
glDrawElements() call. A corner specifies an element
consisting of a vertex, a normal, and a texture coordinate.
If there are any vertices, normals, or texcoords within the
drawInfo block, then the corners will refer to internal data.
Otherwise, the corners will use the v/n/t data in the normal
part of the mesh block.

The dlist keyword is used to indicate that the client should
attempt to use a GL display list to render that part of the
object. dlist at the beginning of a drawInfo block indicates
that the client should try to use display lists for all members.

lengthPerPixel is used to control which LOD is rendered,
for both the main viewport and the radar. For the viewport, it is
affected by the field of view, the pixel resolution, and the distance
between the eye and the object. For the radar, it's derived
straight from the viewed distance and the number of pixels across
the radar (ex: seeing 800m world distance across with 400 pixels
gives a value of 2).

decorative indicates that you don't want older clients to see
this mesh at all. Large drawInfos can easy eat all of the memory
on older clients when used with groups. Vertices, normals, and
texcoords are replicated for each copy of a mesh in the older
clients even if no faces are specified. The is a check is bzfs to
make sure that you aren't tyring to apply 'decorative' to meshes
that might affect the physics of the game.

angvel specifies the dynamic angular velocity
(degres per second).


Quick notes:
- the drawInfo block is documented in the bzw man page
- there are 10 different drawing modes (points, lines, tris, quads, etc...)
- the extents and sphere values are automatically
calculated by bzfs if they aren't specified. They control the culling
and the back-to-front sorting of the object. There are cases when
you might need two drawInfo, but still want them sorted using the
same data.


P.S.
The figure eight animation of the ball was done using two copies
of a group definition containing a mesh that uses a drawInfo block.
It also uses two dynamic colors and a texture matrix to invert on
one side of the figure eight.

P.P.S.
There are two other new features that are related to drawInfos:
1. I added a time syncing feature so that all 2.0.4 clients will
have the same view on their screen at any given time. It's even
been lag compensated (esp. good for animated meshes).
2. Got another feature in today, matswap old new. Unlike
matref used in group instances, matswap is a one-to-one
swap. This should make managing materials for complicated
meshes a little easier.
As for the order of corners, see the openGL docs on glDrawElements()

good luck

User avatar
Macrosoft
Private First Class
Private First Class
Posts: 142
Joined: Fri May 04, 2007 2:21 am

Post by Macrosoft » Thu Sep 06, 2007 12:29 am

if i am reading the above post correctly, corners identify a point where a vertex, normal, and texcoord all exist at the same (x, y, z) point. is that what it says?
gazz: A bullet may have your name on it, but shrapnel is addressed "to whom it may concern".
http://bash.org/?785529

anomaly
Private First Class
Private First Class
Posts: 220
Joined: Tue Jul 26, 2005 10:32 pm
Location: Gainesville Florida

Post by anomaly » Thu Sep 06, 2007 1:08 am

yes. each vertex has a normal and a texcoord.

User avatar
optic delusion
Special Forces
Special Forces
Posts: 995
Joined: Sat Sep 25, 2004 2:29 pm
Location: Planet MoFo
Contact:

Post by optic delusion » Thu Sep 06, 2007 4:43 am

I promised to make a post over here about two months ago ... http://mybzflag.net/ ... Now I'm promising to finish that post.
In the meantime, here's a couple quick thoughts.


Tanks with Oscillation Overthruster do NOT suffer client crash when they enter Drawinfo objects.
I'm sorry for starting the rumor that they do. Clients will only crash when they enter BADLY MADE drawinfo objects, like the pyramid that I made for April Fools day.
http://my.bzflag.org/bb/viewtopic.php?t ... t=drawinfo

Louman did not make the trees/shrubs that he uses, trepan made them.
If I were you, zHero, I would experiment with the shrubs or trees in louman maps. Start by adding angvel, scale or rotate the group, just play around, you'll learn a lot. (shrubs are easier)
Take a look at my Defender game mode concept.

Thinking is not an automatic process. A man can choose to think or to let his mind stagnate, or he can choose actively to turn against his intelligence, to evade his knowledge, to subvert his reason. If he refuses to think, he courts disaster: he cannot with impunity reject his means of perceiving reality.

User avatar
Tedius
Sergeant First Class
Sergeant First Class
Posts: 142
Joined: Tue Sep 19, 2006 6:10 pm
Contact:

Post by Tedius » Thu Sep 06, 2007 3:16 pm

For what it is worth, here is an example of a simple trifan, that is, all triangles fan out from a single point.
Tedius' spinning parasol:

Code: Select all

material
	name wtf
	addtexture http://images.bzflag.org/wtf.png
end

define parasol
	meshbox #parasol pole
		position 0 0 2
		size .25 .25 14
	end
	mesh
		vertex 0 0 15				#0
		vertex 0 -20 10				#1
		vertex 14.142 -14.142 10	#2
		vertex 20 0 10				#3
		vertex 14.142 14.142 10		#4
		vertex 0 20 10				#5
		vertex -14.142 14.142 10	#6
		vertex -20 0 10				#7
		vertex -14.142 -14.142 10	#8
		normal 0 0 20 
		texcoord .5 .5				#0
		texcoord .5 0				#1
		texcoord 1 0				#2
		texcoord 1 .5				#3
		texcoord 1 1				#4
		texcoord .5 1				#5
		texcoord 0 1				#6
		texcoord 0 .5				#7
		texcoord 0 0				#8

	drawInfo
		corner 0 0 0 
		corner 1 0 1
		corner 2 0 2
		corner 3 0 3
		corner 4 0 4
		corner 5 0 5
		corner 6 0 6
		corner 7 0 7
		corner 8 0 8
		angvel 20
		lod #1
			lengthPerPixel 0
				matref wtf
					trifan 0 1 2 3 4 5 6 7 8 1
				end
		end #lod 1
		lod #2
			lengthPerPixel 0.2
				matref wtf
					trifan 0 2 4 6 8 2
				end
		end #lod 2
	end #drawinfo	
	end #mesh
enddef
group parasol
end
Let me know if I am missing anything that is actually necessary (dlist? sphere?).
Lots of thanks go to Optic Delusion for his help on this and his extensive research on the subject.
this signature intentionally left blank

z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

Post by z[h]ero » Thu Sep 06, 2007 5:24 pm

Tedius' spinning parasol:
I tried it out, nice work.
But its weird, shortly before i drive under the rotating umbrella, it disappears!? Is it cause the drawInfo isnt perfect? Or is it in general that rotating objects have this bug in bz when driving under them?

Angvel:
And the angvel again definitely isnt for me per second, and isnt per minute, too. Its several times slower then per minute. Common sense says: if u use "angvel 20" then its not per second, if the object rotates for u guys 20 per minute, then i have again one more bug in my buggy bz.
And if it rotates for each client with cpu-depended speed then we have another problem.


Anyway, its now clear for me that i am out, cause my mesh has a size of xx KB.
Last edited by z[h]ero on Thu Sep 06, 2007 7:05 pm, edited 1 time in total.
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."

User avatar
Teppic
Private First Class
Private First Class
Posts: 575
Joined: Mon Mar 07, 2005 10:00 pm
Location: The North Block
Contact:

Post by Teppic » Thu Sep 06, 2007 6:24 pm

Has anyone considered angvel may be in radian/sec or deg/sec?

User avatar
JeffM
Staff Sergeant
Staff Sergeant
Posts: 5182
Joined: Fri Dec 13, 2002 4:11 am
Location: https://github.com/OmniTanks
Contact:

Post by JeffM » Thu Sep 06, 2007 6:26 pm

code uses it as degrees / sec

z[h]ero
Private First Class
Private First Class
Posts: 204
Joined: Mon Jan 31, 2005 12:00 am
Location: hiding behind box...a real Bz coward :/

Post by z[h]ero » Thu Sep 06, 2007 6:59 pm

JeffM wrote:code uses it as degrees / sec
True, my fault, so bz-docu is right, too. I measured again, this unit suits perfect.
I accidently readed rotations/sec instead degr./sec.
Wirth's law: "Software is getting slower more rapidly than hardware becomes faster."

Post Reply