I figured this out, maybe it can help someone else:
; 1-------3-------4-------2   Cube = 8 vertices

; | E __/|\__ A | H __/| =================
; | __/ | \__ | __/ | Single Strip: 4 3 7 8 5 3 1 4 2 7 6 5 2 1
; |/ D | B \|/ I | 12 triangles: A B C D E F G H I J K L
; 5-------8-------7-------6
; | C __/|
; | __/ |
; |/ J |
; 5-------6
; |\__ K |
; | \__ |
; | L \| Left D+E
; 1-------2 Right H+I
; |\__ G | Back K+L
; | \__ | Front A+B
; | F \| Top F+G
; 3-------4 Bottom C+J
{ 0.5, 0.5, 0.5 }, ;4
{ -0.5, 0.5, 0.5 }, ;3
{ 0.5,-0.5, 0.5 }, ;7 A front
{ -0.5,-0.5, 0.5 }, ;8 B front
{ -0.5,-0.5,-0.5 }, ;5 C bottom
{ -0.5, 0.5, 0.5 }, ;3 D right
{ -0.5, 0.5,-0.5 }, ;1 E right
{ 0.5, 0.5, 0.5 }, ;4 F top
{ 0.5, 0.5,-0.5 }, ;2 G top
{ 0.5,-0.5, 0.5 }, ;7 H left
{ 0.5,-0.5,-0.5 }, ;6 I left
{ -0.5,-0.5,-0.5 }, ;5 J bottom
{ 0.5, 0.5,-0.5 }, ;2 K back
{ -0.5, 0.5,-0.5 } ;1 L back
Cool ASCII art, huh? :grin:
Posted on 2002-06-25 22:57:31 by bitRAKE
Yup cool ASCII skills and interesting suff ;)
Posted on 2002-06-26 18:11:27 by BogdanOntanu
This tool is very useful

Posted on 2002-06-28 16:13:04 by minimoog
I'm going to work on my own tri-strip program. Using tri-strips indices is faster than just plain tri-strips. I have been doing some research:
Xinyu Xiang's thesis is a very good read.

NVidia's tri-strip program is not so good.
Most important part is cache coherency.
Posted on 2002-06-28 20:12:14 by bitRAKE
( never mind that, I figured it out, but what are they for?)
Posted on 2002-06-29 04:07:22 by AmkG
IMHO, heavy triangle stripping is good for static vertex data.

I'm interested to see it your own tri-strip program.

If you don't mind to share it when it's finished.:cool:
Posted on 2002-06-29 04:12:23 by minimoog
Afternoon, bitRake.

I've used your tri-strip thingy in a little example (Here ).

Posted on 2002-06-29 09:05:24 by Scronty
Thanks, Scronty. :)
Posted on 2002-06-29 11:06:21 by bitRAKE
Afternoon, bitRAKE.

( only the light rotates? )

ummm.....the cube should be rotating as well:/

Is the cube not rotating at all?

Posted on 2002-06-29 19:59:47 by Scronty
Maybe your computer is so fast (or the code is so optimised :) ), that the cube rotates in phase with your CPU so it looks stationary :p
Posted on 2002-06-29 22:54:17 by jademtech
where is winextra.def , d3dx8.inc d3dx8.lib and d3d8.lib ???

Thanks in advance
Posted on 2002-06-30 14:36:05 by mnemox
Hi scronty, the cube is rotating well.

winextra.def , d3dx8.inc d3dx8.lib and d3d8.lib are found at scronty's website but since his site is under construction, I guess you have to wait. I have his dx incs and libs but it's over 3mb++
Posted on 2002-06-30 17:11:57 by stryker
Afternoon, mnemox.

Have you got DX8.1 installed on your computer?

Also: the DX stuff on my page is under that "under construction" page. You only have to scroll down a bit ;p

Posted on 2002-06-30 17:55:51 by Scronty

Is the cube not rotating at all?
Nope, not at all. I have DX8.1 installed.
Wonder what the problem is?

Here is a picture of what I get:
Posted on 2002-06-30 22:55:42 by bitRAKE

IMHO, heavy triangle stripping is good for static vertex data.

I'm interested to see it your own tri-strip program.

If you don't mind to share it when it's finished.:cool:
I don't really understand: what situations exist where vertex data is not static? I suppose there are going to be several version of my tristrip stuff - some of them will be posted here in time.
Posted on 2002-07-01 11:15:16 by bitRAKE
Scronty, found the problem: you can't rely on "invoke timeGetTime" when used with FPU math - my system has been up for several weeks and this produced a value that is out of range. This explains problems I've had with many examples. Here are some links to others with the same problem:

http://www.andypike.com/tutorials/directx8/003.asp http://www.gamedev.net/community/forums/topic.asp?topic_id=96690
Posted on 2002-07-01 13:17:05 by bitRAKE
Static vertex means that untransformed parameters (vertex coordinates, vertex normal, texture coordinates) of vertex are not changing.

One simple example is drawing ocean with waves...

Maybe this is trivial, but change vertex 4 of tri strip cube to let say to (0.5, 0.5, 0.6). You have to go through stripe and change also "F top". Of course you can do this by "hand" but what about model with 1000 polygons? How would you know if you change some vertex where and in which strip this vertex appear? You can use some indexing (similar to wavefront .obj file format, first vertex coords then how they are connected), but then you must search through connections...Maybe there are other solutions for this.
Posted on 2002-07-01 14:20:28 by minimoog
minimoog, that is what vertex shaders are for. The geometry stays constant vertices are transformed on the GPU. The only thing that can't be done easily is adding/removing vertices, but this can be faked. They should be indexed to have no duplicate vertices. The wave example can be done with a parametric surface: all you do is send the vertices for a quad and have the GPU create the geometry and transform to create waves. :) You would have to create the geometry yourself to merge it with a shore, or find another solution to fake that interaction as well - you know it is all smoke and mirrors. :)
Posted on 2002-07-01 14:31:41 by bitRAKE
bitRAKE you are right.:alright:

Idea: what about triangle fanning? And what about combination triangle stripping with triangle fanning?
Posted on 2002-07-01 17:24:25 by minimoog
minimoog, what I have read and my own intuition lead to fans are not so good - not many areas wound be better suited to fans - fans just cover a unique instance where triangle strips aren't good, imho. If you have a single strip then you only need one API call to draw it - any shapes can be done with a strip using degenerate triangles (zero area). NVidia tests show better performance by sending more triangles to GPU each API call, therefor solution is triangle strips for everything, imho. Instead the model should be divided into groups based on shader requirements - I need to run some of my own tests to confirm this. NVidia also states that the GPU is almost never the bottleneck (key statement, "GPU reads from main memory run at 10% of theroretical." :( ). "CPU is the bottleneck even on 1.5Ghz machine."

I want to minimize CPU usage, and maximize GPU throughput. So, my design will be around using data that is in GPU memory to it's fullest and updating those buffers very rarely (compared to screen update). Some vertex and index set management must take place on the CPU side in order to have a single buffer for each (same for textures, btw :)). Thanks for your interest.
Posted on 2002-07-01 18:14:00 by bitRAKE