Procedural Road Help

#1 What's working and what's not? Does it render at all right now?

#2 @Stefan: it renders well and it appears to be lightweight.

I've kind of hit the same stumbling block that Ron has though. Anytime I try to complete a loop it causes a crash and I'm afraid that intersections may do the same. I've also yet to get collision working. I thought it would be simple but I just can't wrap my mind around it since it's not a true shape, per se.

#3 I just wanted to add to what Mike Hall had said in that I have tried to convert this to a TSMesh and a TSShape without success. In both cases, if successfully done you caould easily add polysoup to the object. A simple dynamic cast is not enough though. I say this because later down the road you will have bit allocation failures because the shape is not setup properly.

Now I did notice that with TSMesh you can set the object to a sceneobject as in this case however, it does not like to assemble properly if you are using TriangleStrips as is done in this case. It will take TriangleFans and TriangleLists and calculate the whole process out nicely, but I have not been successful in changing the rendering to such a method without totally screwwing up the process.

#4 Ron,

Remember that if you change the whole shape into a TSShape, you'd lose any custom culling that you might want to implement in the future. If your road system gets large, lacking this will be noticable.

I would love to take a look at this and implement collision, but no time at the moment. :(

#5 Well then I would ask your recommendation, would you convert the object to a TSMesh, TSSHape, TSStatic, or just leave it as is and create a completely different method of using polysoup with it?

#6 Not sure Ron. The only thing I've figured out so far is that the spline path code is used to place the road geometry. I would naturally begin as you've begun since it hopefully means less work, and you can't really modify a TSShape directly (which as far as I understand is needed here when the road curves) unless you go about it in the vertex shader.

There are other factors. Lightmapping, shaders, collision, custom rendering. I definatly wouldn't touch with TSMesh or TSStatic, though.

#7 Well I took your advice and some really good advice from Tom Spilman in regards to the code for generating the bounding box. Tom was definitely right the bounding box was not being generated correctly and after severely revising that section, the code now properly calls upon buildConvex, buildPolyList, and castRay.

I have completely cut out the stuff I was trying to do to force it to be a TSStatic and TSShape and will now try to design it with its own working convex and polyList methods.

I updated the code at the links above so anyone faster than I am can get to it.

#8 You could convert it to several TSShapes, which would allow custom culling and probably make collision a lot faster.

#9 Well that would probably be a bit of trouble Dan with putting it all together. However, I am able to figure out everything in putting something together with one exception, primitives.

#10 OK I have figured out to do this properly it will have to be done in a manner similar to that which was used to create the indices and primitive lists for the water block, with one big exception the fxRoad is not a square object. I have tried the allocation system that TSMesh uses already and it crashes the engine when trying to do this.

You can see how the water block does its indices in WaterBlock::setupPrimitiveBlock. My theory is that to do this properly the code needs to be changed in the rendering and contruction departments. What I believe has to be done is create vertex and primitive buffers for the three sections and render them that way. You would be creating the indices, and buffers at time when you are constructing the mesh in the updateRoad() function.

That way you could just accumulate the verts, tVerts, indices, and primitives into a full list of all three for purposes of determining collision.

I haven't time to do this right now since I have automotive work to do today, but I would really appreciate it someone could give it a try.

#11 Wait, why do you need to change the rendering?

#12 Well I suppose you don't have to, but it seems a bit silly to put together a vertex and primitive buffer and not use it to render as well.

#13 Would someone help me get the indices set up? For one I am not quite sure the order the vertices are being added to make each triangle. I have to admit I have no idea where to start with this. Its not like it is a simple shape.

#14 Me neither, which is why I would begin with collisions. :P

#15 Ok Stefan, how would you go about do that? If I am not mistaken, if I want to add Polysoup to this, I need indices and primitives. If you hava nother way, please enlighten me.

#16 There was a constructor shape thingie in 1.03 that was small enough to give a fairly good idea on how to make the indices setup work, with collisions and passing it to a buffer. Not sure where it is right now. :/

#17 Stefan, I am pretty certain I found what you were talking about in Constructors Simple Mesh code, however, it too is based upon TSMesh's primitives and indices. It just repacks them.

#18 It would be much more memory-efficient to create the vertecies, once, in mIndices, then say

U16 *indices = mIndices.address();

#19 Yeah well I am going I am going a single route anyway. It might not even be necessary to compile the primitives is the indices are done correctly.

#20 I have uploaded my latest. Almost all of the Polysoup code is complete, but it doesn't work quite right and causes crashes. I am certain that it is due to the way I am setting up my indices in construction and in polysoup collision.

Please have a look and point out my mistakes.