Elvas Tower: Plotting shapes from *.s files - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Plotting shapes from *.s files Do *.s files contain flags specifying the triangles to plot? Rate Topic: -----

#1 User is offline   David Webb 

  • Apprentice
  • Group: Status: Active Member
  • Posts: 36
  • Joined: 05-January 20
  • Gender:Male
  • Simulator:OpenRails, ZR
  • Country:

Posted 26 July 2020 - 08:52 AM

I've being trying to plot some *.s files using OpenGL. Looking at Shape.cs, final 3-D plotting seems to be through a few calls to the DirectX method 'DrawIndexedPrimitives' with an array of pointers named TriangleList which I take to imply that the resulting 3-D vertices and texture coordinates are used to plot a series of 3-D triangles (GL_TRIANGLE_LIST in OpenGl).

This obviously works when all the triangles are adjacent and the points well ordered - but at times the series of vectors jumps from one part of the structure, say a wall, to the next, say a roof. This produces odd triangles with no purpose - but I cannot find any flag which says they should not be plotted, that there is a break in the sequence or that something else, say a quad_strip should now be used.

Can anyone help - or point me to the right document.

Thanks,

D.

#2 User is offline   gpz 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,772
  • Joined: 27-October 12
  • Gender:Male
  • Location:Budapest
  • Simulator:OpenRails
  • Country:

Posted 27 July 2020 - 04:12 AM

My first guess would be that you are drawing without taking the index buffer into account, and using the DrawPrimitives instead of the DrawIndexedPrimitives. The index buffer's purpose is to define the order in which the vertices in the vertex buffer are drawn, so they will not be drawn just purely sequentially and are not needed to be well ordered.

#3 User is offline   David Webb 

  • Apprentice
  • Group: Status: Active Member
  • Posts: 36
  • Joined: 05-January 20
  • Gender:Male
  • Simulator:OpenRails, ZR
  • Country:

Posted 27 July 2020 - 06:57 AM

Peter, thanks for getting back.

No I am looping through vertex array of each sub-object and picking up the points and normals from there.

I thought the key might be in one of the other arrays - geom_nodes, node_maps, n_vertex_sets, tri_lists etc but in the cases I've checked they are all too small (I do not understand what they all do yet).

One alternative is to skip when the normals change more than a reasonable amount (say 20 degrees) but although it might work in many/most cases there must be a better (correct?) way.

I see there is something on .s files in one of the download directories - but unless I add another 45 or so comments to this topic it will be off limits to me for some time.

David

#4 User is offline   gpz 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,772
  • Joined: 27-October 12
  • Gender:Male
  • Location:Budapest
  • Simulator:OpenRails
  • Country:

Posted 27 July 2020 - 10:28 AM

I don't know the .s format in details, but there must be an index list somewhere, it is probably the one you mentioned as tri_lists. It is an array of single integer numbers, and yes, it is much smaller than the vertex buffer, which is position+normal+texture. The index buffer tells you in what order you must use the vertices. But you don't have to process that, just upload that to the GPU memory together with the vertices data, and let that deal with that :)

#5 User is offline   David Webb 

  • Apprentice
  • Group: Status: Active Member
  • Posts: 36
  • Joined: 05-January 20
  • Gender:Male
  • Simulator:OpenRails, ZR
  • Country:

Posted 27 July 2020 - 11:42 AM

 gpz, on 27 July 2020 - 10:28 AM, said:

I don't know the .s format in details, but there must be an index list somewhere, it is probably the one you mentioned as tri_lists. It is an array of single integer numbers, and yes, it is much smaller than the vertex buffer, which is position+normal+texture. The index buffer tells you in what order you must use the vertices. But you don't have to process that, just upload that to the GPU memory together with the vertices data, and let that deal with that :)


I don't think it is the tri list, as this is usually a list with only one element. I'll give this problem a break for a few days and try again. Maybe I'll see something then. But thanks for the suggestion. D.
p.s I have not moved onto GPUs and shaders yet - I had to do some 3-D graphics about eight years ago so I am still using what I picked up then.

#6 User is offline   David Webb 

  • Apprentice
  • Group: Status: Active Member
  • Posts: 36
  • Joined: 05-January 20
  • Gender:Male
  • Simulator:OpenRails, ZR
  • Country:

Posted 30 August 2020 - 03:22 AM

Sorted - a programming error set the number of tri-lists to zero. D.

p.s. For those that are a bit baffled, each tri-list contains information on parts of the shape structure using the same texture file (and other properties: shader, light, z buffer, alpha test, zbias - in one of the 'primitive state' structures). Information on the shape to plot is contained in a list, part of the tri-list structure, each element of which contains three integers, each corresponding to one corner of a triangle that needs to be plotted.

Each of the integers is then the index to items in similar positions in each of the vertex, normal and texture arrays higher up the tree at the sub-object level. These in turn refer to one of the corresponding sets of 3, 3 and 2 dimensional (floating point) vectors at the top level of the shape structure - i.e. the values actually needed to plot the 3D shape. Easy (maybe)!

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users