Sim development--Skies!

Ok gang... Take a look at the first pic here please: http://performancesimulations.com/scnshot4.htm The age old question... How do I get rid of the seams at the edges of the sky? They're visible between all 13 panels. Thanks, Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

Looks cool! nice texture! I am not sure how to get rid of the edges :( Hows it done? , I was thinking of sticking a sky in mine - now i have, wait for it.....GRASS!! :D Ash http://www.siroccoracing.com J. Todd Wasson wrote:

Quoted text (7 lines)

> Ok gang... Take a look at the first pic here please: > > http://performancesimulations.com/scnshot4.htm > > The age old question... How do I get rid of the seams at the edges of the > sky? They're visible between all 13 panels. >

[email hidden] (J. Todd Wasson) writes: > Ok gang... Take a look at the first pic here please: > > http://performancesimulations.com/scnshot4.htm love the textures, man. did you "make" them yourself? > The age old question... How do I get rid of the seams at the edges of the > sky? They're visible between all 13 panels. looks like T-junctions. if that's the problem, you just need to make sure not to place vertices along an edge (without splitting it, that is). hope that makes sense. -- Gunnar #31 SUCKS#015 Tupperware MC#002 DoD#0x1B DoDRT#003 DoD:CT#4,8 Kibo�: 2 DE RECTIS NON TOLERANDUM EST

Make sure the vertices for the cub map are welded together and in fact share the same vertex for all the polys. "J. Todd Wasson" <[email hidden]> wrote in message news:[email hidden]... > Ok gang... Take a look at the first pic here please: > > http://performancesimulations.com/scnshot4.htm > > The age old question... How do I get rid of the seams at the edges ofthe

Quoted text (14 lines)

> sky? They're visible between all 13 panels. > > Thanks, > > Todd Wasson > --- > Performance Simulations > Drag Racing and Top Speed Prediction > Software > http://PerformanceSimulations.Com > > My little car sim screenshots: > http://performancesimulations.com/scnshot4.htm >

>love the textures, man. did you "make" them yourself? > > Thanks.. Someone made the road texture for me. The sky is from a GPL update. The creator says to go ahead and use 'em for sims and what-not, so might as well take advantage of it. This particular sky is supposed to be for Nurburgring (sp?), although I bet it looks better in GPL :0) >looks like T-junctions. if that's the problem, you just need to make >sure not to place vertices along an edge (without splitting it, that >is). hope that makes sense. > I'm not using the 3-D model itself directly for the sky. Instead, I'm just making a couple points for the bottom and top at each vertical edge, then spinning it around xx degrees at a time and laying out the textures in quads as I go. So... The edges of the vertical quads are using the same vertices, which is what's bugging me.. It seems they should all match up and look perfect, but of course they don't.. I get more admiration for real game developers every day. :0) I might try making them overlap/pierce through each other near the edges a little, maybe that'll help. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

>Make sure the vertices for the cub map are welded together and in fact share >the same vertex for all the polys. Thanks, Chris. The top poly is just crudely laid on top of the sky "cylinder", so I'm not too concerned with that one in particular. The vertical walls all share vertices at the corners, however, and still have seams. ? Wierd... Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

>Looks cool! nice texture! I am not sure how to get rid of the edges :( > >Hows it done? , I was thinking of sticking a sky in mine - now i have, >wait for it.....GRASS!! :D > Thanks :0) Thanks anyway... I don't know either.. Nice looking grass! (in sequential answering order) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

Are you using OpenGL Todd? Long time since I used it but I know there's a texture clamping toggle thing in the OpenGL instruction set, erm.... you need to turn the clamp on, draw sky polys, then turn the clamp off again. Worked for me when I had this same problem using Quake3 skies. The texture clamp thing is used to prevent e.g the extreme left hand pixel on each line of the texture from being blended into the extreme right hand pixel, which is done when OpenGL thinks you're tiling. Here you're not. Gah I'm gabbling, I don't suppose that's going to make much sense. Good luck with it and I'll try to dig out my old program and see what I did for skies in there. Cheers Jim "J. Todd Wasson" <[email hidden]> wrote in message news:[email hidden]... > >Make sure the vertices for the cub map are welded together and in factshare > >the same vertex for all the polys. > > Thanks, Chris. The top poly is just crudely laid on top of the sky > "cylinder", so I'm not too concerned with that one in particular. Thevertical

Quoted text (16 lines)

> walls all share vertices at the corners, however, and still have seams. ? > Wierd... > > > > > Todd Wasson > --- > Performance Simulations > Drag Racing and Top Speed Prediction > Software > http://PerformanceSimulations.Com > > My little car sim screenshots: > http://performancesimulations.com/scnshot4.htm >

On 22 Jan 2002 14:58:21 GMT, [email hidden] (J. Todd Wasson) wrote:

Quoted text (7 lines)

>>Make sure the vertices for the cub map are welded together and in fact share >>the same vertex for all the polys. > > Thanks, Chris. The top poly is just crudely laid on top of the sky >"cylinder", so I'm not too concerned with that one in particular. The vertical >walls all share vertices at the corners, however, and still have seams. ? >Wierd...

Hi Todd, nice eh, those skies? Notice I have a tutorial one those, to go from those skies to Racer DOF files; importing the horizon .3do and such (it's a bit of a mess since 3do-s are trees and DOF is a linear format). In a new small shot with the new P4 on the opening page, you can see the Sears sky (click the image for a 800x600 shot; notice a seam!). But take note, that the author has taken the images from N4, and edited them, so there may still be some copyright issues. But they sure look great (that's why I did the tutorial). The 3do I used is a bit less crude than the seam you have between the side and top walls. The problem here is wrapping (or rather, repeating). Set the glTexParameter(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T) and WRAP_S to GL_CLAMP or GL_CLAMP_TO_EDGE (I think the latter is better, but requires an extension). You're seeing the S/T parameters wrap on to the start of the texture. I once tested this, and it worked for me. Unfortunately, this parameter is hidden a bit deep in all my model classes (so the problem persists without serious hacking based on texture names or something). Doesn't matter, as I plan a Quake-style shader rendering engine anyway for the future, which will deal with this in a more flexible way. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

[email hidden] (J. Todd Wasson) writes: > I'm not using the 3-D model itself directly for the sky. Instead, I'm just > making a couple points for the bottom and top at each vertical edge, then > spinning it around xx degrees at a time and laying out the textures in quads as > I go. So... The edges of the vertical quads are using the same vertices, > which is what's bugging me.. It seems they should all match up and look > perfect, but of course they don't.. do you still get seams if you fill the polygons with a solid color (instead of texturing them)? -- Gunnar #31 SUCKS#015 Tupperware MC#002 DoD#0x1B DoDRT#003 DoD:CT#4,8 Kibo�: 2 silence is FOO!

>do you still get seams if you fill the polygons with a solid color >(instead of texturing them)? Good idea... Just trying it now and... Nope, no seams, just a solid color everywhere.. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

Quoted text (8 lines)

>Hi Todd, nice eh, those skies? Notice I have a tutorial one those, to >go from those skies to Racer DOF files; importing the horizon .3do and >such (it's a bit of a mess since 3do-s are trees and DOF is a linear >format). >In a new small shot with the new P4 on the opening page, you can see >the Sears sky (click the image for a 800x600 shot; notice a seam!). > >

I got the link from your tutorial, and those are the nicest skies I've seen yet. I still haven't figured out your DOF files yet. If there's more than one INDI chunk, I usually have problems, but that's another thread in itself. Some of my smaller experimental models work, but the only complex models that will load are completely contained in one INDI chunk. All tutorials I've seen on 3-D file loading are in C++; OOP is something I don't know anything about yet, so seeing little symbols like -> just confuse me, leaving me to reinvent the wheel in the 3-D model loading department, or hunting endless for straight C examples (haven't found any). Perhaps I ought to take up some basic C++? Is it the quantum leap mentally that I imagine it is? >But take note, that the author has taken the images from N4, and >edited them, so there may still be some copyright issues. But they >sure look great (that's why I did the tutorial). Shucks... The mip to bmp converter from your site really did the trick. I didn't load the models really, just generated the sky box with a rotation formula and mapped the bmp's to it. They are beautiful, that's for sure! Thanks for posting the link :0) >The 3do I used is a bit less crude than the seam you have between the >side and top walls. The problem here is wrapping (or rather, >repeating). Set the glTexParameter(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T) >and WRAP_S to GL_CLAMP or GL_CLAMP_TO_EDGE (I think the latter is >better, but requires an extension). Thanks for the tip.. I just tried this as suggested, and it looks the same still :-( Perhaps slightly better at times maybe, but the seams are still visible.. Jim Seamus said something about switching clamping on and off during rendering, you know anything about that? I thought that was a DX thing, but maybe that's just for rendering surfaces and I'm confusing the two.

Quoted text (7 lines)

>You're seeing the S/T parameters wrap on to the start of the texture. >I once tested this, and it worked for me. Unfortunately, this >parameter is hidden a bit deep in all my model classes (so the problem >persists without serious hacking based on texture names or something). >Doesn't matter, as I plan a Quake-style shader rendering engine anyway >for the future, which will deal with this in a more flexible way. >

Do you have a declaration # for GL_CLAMP_TO_EDGE? It's not in my header file. (Converted to PowerBasic, so maybe everything's not there.) Don't look too hard, I want to see if there's another way to fix this. My road textures don't have this problem. The quake style engine sounds awesome... I'm just trying to draw basic stuff at this point! LOL Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

Quoted text (15 lines)

>Are you using OpenGL Todd? Long time since I used it but I know there's a >texture clamping toggle thing in the OpenGL instruction set, erm.... you >need to turn the clamp on, draw sky polys, then turn the clamp off again. >Worked for me when I had this same problem using Quake3 skies. > >The texture clamp thing is used to prevent e.g the extreme left hand pixel >on each line of the texture from being blended into the extreme right hand >pixel, which is done when OpenGL thinks you're tiling. Here you're not. > >Gah I'm gabbling, I don't suppose that's going to make much sense. Good luck >with it and I'll try to dig out my old program and see what I did for skies >in there. > >Cheers >Jim

Yes, it's OpenGL.. Ok, Ruud just outlined clamping, is that what you were talking about? I tried what he mentioned, but the problem is still there. However, I'm not switching clamping on and off at anypoint, it's just set "on" one time when the textures are loaded with: glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_REPEAT glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_T,%GL_REPEAT Look familiar? Anything glaringly wrong here? Thanks, Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

The clamping thing, as explained by someone who understands the problem but lacks the technical vocabulary (sorry!): OpenGL repeats textures if you set the u,v to more than 1, as you know. This makes it dead easy to tile a floor with a single texture, for example. The "texture filtering thing" blends each texture pixel with its neighbours, so when a texture is seen at an angle or stretched or whatever it doesn't look blocky. So when you move really close to the floor and look down, you don't see giant hard-edged pixels. If you have a floor texture that ISN'T repeated (i.e. no tiling), then OpenGL still uses the same texture filter thing whereby every pixel is blended with its neighbours. The thing is, the pixels on, say, the very left side of the texture have "neighbours" on the very right side (because you have GL_REPEAT or whatever its called on, so OpenGL is prepared for repeating textures). So the colour of the pixels on the left hand edge of your texture is influenced by the colour of the pixels on the right. It is this that's causing the visible edges in your sky. You need to "clamp" the texture edges in OpenGL so that it doesn't wrap around to the far edge of the texture when looking for neighbour pixels. This way the edge pixels will be unaltered and so will match up with the pixels of the adjacent sky poly. Is this making any sense? As I said, I don't have the technical vocab but I understood and solved the problem once before (can't find my bloody source code though at the moment to find the name of the GL_ command). Hope this helps anyway, g'luck Jim "J. Todd Wasson" <[email hidden]> wrote in message news:[email hidden]... > >Are you using OpenGL Todd? Long time since I used it but I know there's a > >texture clamping toggle thing in the OpenGL instruction set, erm.... you > >need to turn the clamp on, draw sky polys, then turn the clamp off again. > >Worked for me when I had this same problem using Quake3 skies. > > > >The texture clamp thing is used to prevent e.g the extreme left handpixel > >on each line of the texture from being blended into the extreme righthand > >pixel, which is done when OpenGL thinks you're tiling. Here you're not. > > > >Gah I'm gabbling, I don't suppose that's going to make much sense. Goodluck > >with it and I'll try to dig out my old program and see what I did forskies

Quoted text (7 lines)

> >in there. > > > >Cheers > >Jim > > > Yes, it's OpenGL.. Ok, Ruud just outlined clamping, is that what you

were > talking about? I tried what he mentioned, but the problem is still there. > However, I'm not switching clamping on and off at anypoint, it's just set"on"

Quoted text (20 lines)

> one time when the textures are loaded with: > > glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_REPEAT > glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_T,%GL_REPEAT > > Look familiar? Anything glaringly wrong here? > > > Thanks, > > Todd Wasson > --- > Performance Simulations > Drag Racing and Top Speed Prediction > Software > http://PerformanceSimulations.Com > > My little car sim screenshots: > http://performancesimulations.com/scnshot4.htm >

In article <[email hidden]>, [email hidden] (J. Todd Wasson) writes: > Ok gang... Take a look at the first pic here please: > >http://performancesimulations.com/scnshot4.htm > > The age old question... How do I get rid of the seams at the edges of the >sky? They're visible between all 13 panels. It still amazes me that *individuals* can write stuff like that. That's cool... eldred -- Dale Earnhardt, Sr. R.I.P. 1951-2001 Homepage - http://www.umich.edu/~epickett GPLRank - under construction... Never argue with an idiot. He brings you down to his level, then beats you with experience... Remove SPAM-OFF to reply.

>OpenGL repeats textures if you set the u,v to more than 1, as you know. This >makes it dead easy to tile a floor with a single texture, for example. No, I didn't know that! :0) >The >"texture filtering thing" blends each texture pixel with its neighbours, so >when a texture is seen at an angle or stretched or whatever it doesn't look >blocky. So when you move really close to the floor and look down, you don't >see giant hard-edged pixels. ><snip> Great explanation, thanks. I'm understanding it better now. I think I've got it licked now for the most part. I had this: glTexParameteri %GL_TEXTURE_2D,%GL_TEXTURE_MAG_FILTER,%GL_LINEAR glTexParameteri %GL_TEXTURE_2D,%GL_TEXTURE_MIN_FILTER,%GL_LINEAR This was causing the textures to do exactly what you just said. By changing the last parameter to GL_NEAREST (disable the texture smoothing), the problem almost completely disappeared because it wasn't try to blend anything at all. Now, there's an occasional flash once in awhile, but for the most part, the problem's gone. I'll get into the clamping and blending next and see how it goes now that I understand much better how this works. Thanks a ton :0) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

On 22 Jan 2002 17:04:09 GMT, [email hidden] (J. Todd Wasson) wrote: ... > Yes, it's OpenGL.. Ok, Ruud just outlined clamping, is that what you were >talking about? I tried what he mentioned, but the problem is still there. >However, I'm not switching clamping on and off at anypoint, it's just set "on" >one time when the textures are loaded with: > > glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_REPEAT Heh, that's not clamping, that's the opposite. Try: glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_CLAMP or if you're in luck: glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_CLAMP_TO_EDGE Quite glaringly wrong. ;-) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Quoted text (12 lines)

>> glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_REPEAT > >Heh, that's not clamping, that's the opposite. Try: > > glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_CLAMP > >or if you're in luck: > > glTexParameterf %GL_TEXTURE_2D,%GL_TEXTURE_WRAP_S,%GL_CLAMP_TO_EDGE > >Quite glaringly wrong. ;-) >

Hehe... I meant to post the GL_CLAMP version instead :-) The GL_CLAMP_TO_EDGE isn't in my header file though :-( Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

On 22 Jan 2002 17:01:23 GMT, [email hidden] (J. Todd Wasson) wrote: > I got the link from your tutorial, and those are the nicest skies I've seen >yet. Very true. Great stuff. > I still haven't figured out your DOF files yet. If there's more than one >INDI chunk, I usually have problems, but that's another thread in itself. Then you probably also have multiple GOB1 chunks; a GOB1 is a geob, which is an object within the geode (the entire file, so to say). Different materials often (if not always) use a separate GOB1 chunk, which uses its own INDI chunk (which is just part of it all; you also will have a VERT chunk for the vertex data etc). So: - A model = a geode - A geode = 1 or more geobs - A geob = vertex/normal/texcoord/index data It gets worse with my own DOF files, as there may be multiple bursts in one geob, but that seems unused in 99% (if not 100%) of the DOF files out there. >All tutorials I've seen on >3-D file loading are in C++; OOP is something I don't know anything about yet, >so seeing little symbols like -> just confuse me, It's really no different from good solid C coding, but a bit more elegantly put. myObject->function(x,y) is what you would write in C as: objFunction(myObject,x,y) It's just better coupled, so data and code are mixed in 1 object, instead of leaving that issue up to the code. >Perhaps I ought to take up some basic C++? Is >it the quantum leap mentally that I imagine it is? It's not, not the basic stuff. Forget templates for a while, forget multiple inheritance (I once wrote a compiler, studied multiple inheritance, then forgot about it for ever more, since it is SO complex to implement, it can lead only to bugs). But if you do do single inheritance, use a virtual destructor in your base class. Remember that. :) > Shucks... The mip to bmp converter from your site really did the trick. I >didn't load the models really, just generated the sky box with a rotation >formula and mapped the bmp's to it. They are beautiful, that's for sure! >Thanks for posting the link :0) You're welcome. > Thanks for the tip.. I just tried this as suggested, and it looks the same >still :-( Perhaps slightly better at times maybe, but the seams are still >visible.. Jim Seamus said something about switching clamping on and off during >rendering, you know anything about that? That was what I was talking about. Basically repeating (as you did before) means just chopping of the integer part and using the decimal part for the coordinates. Near the edges, it will wrap, which you don't want, but you want it to clamp instead, so 1.001 would become 1.0, instead of 0.001. > I thought that was a DX thing, but >maybe that's just for rendering surfaces and I'm confusing the two. DX and OpenGL are largely the same, DX just came about 10 years later and took 8 versions to get up to speed. :) After knowing OpenGL, reading a D3D book will almost get you started on OpenGL things as well, since most parameters look the same, it's just with D3D you have to type 2x or 3x more to get the same thing done. And don't forget that for DX9 you'll have a ball converting your stuff to the new API. ;-) ... > Do you have a declaration # for GL_CLAMP_TO_EDGE? It's not in my header >file. #define GL_CLAMP_TO_EDGE 0x812F I'm sure though you cannot just use this, even if it might work. There's an extension you have to check for. > (Converted to PowerBasic, so maybe everything's not there.) Don't look >too hard, I want to see if there's another way to fix this. My road textures >don't have this problem. Since you created the dots yourself, why not do a triangle strip (if you're not already doing so)? That will ensure you have correctly shared vertex data. > The quake style engine sounds awesome... I'm just trying to draw basic stuff >at this point! LOL It's really quite simple in fact; the basic problems are just twofold; one is creating a shader sort key from the shader's properties, and the other is making good use of multitexturing when possible. Basically you have: struct RenderData { float *vertexData; float *normalData; //etc int sortkey; }; You put everything you want to draw in a big list, quicksort on sortkey, then render in passes. The passes are walked piece by piece, and only flushed when a pass can't be added to the previous pass. Works for Quake. :) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

He speaks! "Chris West" <[email hidden]> wrote in message news:KLe38.2000$[email hidden]... > Make sure the vertices for the cub map are welded together and in factshare > the same vertex for all the polys.

On Tue, 22 Jan 2002 21:54:26 GMT, "David L. Cook" <[email hidden]> wrote: >He speaks! And programs. :) >"Chris West" <[email hidden]> wrote in message >news:KLe38.2000$[email hidden]... >> Make sure the vertices for the cub map are welded together and in fact >share >> the same vertex for all the polys. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Quoted text (9 lines)

>> I still haven't figured out your DOF files yet. If there's more than one >>INDI chunk, I usually have problems, but that's another thread in itself. > >Then you probably also have multiple GOB1 chunks; a GOB1 is a geob, >which is an object within the geode (the entire file, so to say). >Different materials often (if not always) use a separate GOB1 chunk, >which uses its own INDI chunk (which is just part of it all; you also >will have a VERT chunk for the vertex data etc). >

Hmm.... Not sure how many GOB1's there were. I haven't changed the loader much from the beginning. Just was trying to get the triangles drawn without worrying about textures and all that (even though you told me it's easier to do it all at once :-)). I'm not too swift with data structures yet (just got some vector functions running with pointers last night done as an experiment, pretty cool stuff.) What I'm doing is scanning for nothing but INDI and VERT chunks. Being a rookie, I actually scan the file four times when loading it (slooowwww.....) First pass is to find the number of INDI chunks. Second pass loads all those indicies, making sure to set them back to 0 (or 1?) at each chunk. Once I did that, some of the little test models with more than one INDI chunk would actually load correctly. The third pass finds the total number of VERT chunks, and the fourth loads the vertices the same basic way. lol If I try to load one of the Porche 911's from SCGT I get the rear plate and exhaust pipes only :-) The other cars turn into a big mess, so something's wrong. Still, I would think that even though the INDI chunks might be in different geobs, they'd still have the same indice values. Maybe not? It's possible that I'm resetting my "indice counter" inappropriately, but it's hard to tell because the simple test models will load. Actually, now that I think about it, there were some exceptions to that... Seems that things would only work if the number of indicies was an odd or even number (can't recall which), or something like that.

Quoted text (12 lines)

>>All tutorials I've seen on >>3-D file loading are in C++; OOP is something I don't know anything about >yet, >>so seeing little symbols like -> just confuse me, > >It's really no different from good solid C coding, but a bit more >elegantly put. >myObject->function(x,y) is what you would write in C as: >objFunction(myObject,x,y) > >It's just better coupled, so data and code are mixed in 1 object, >instead of leaving that issue up to the code.

Oh, ok.. Maybe it's something I can learn then (although I doubt I could write a compiler!!! Geeze...lol) I look at the C++ primer in Lamothe's "Tricks of the Windows Game Programming Gurus" from time to time to get the (very) basic gist of things in my head. I'm just messing with pointers now for the first time. Maybe after getting a better grip of those along with data structures and such, I could move on to C++. Maybe.... Just maybe ;-)

Quoted text (10 lines)

>>Perhaps I ought to take up some basic C++? Is >>it the quantum leap mentally that I imagine it is? > >It's not, not the basic stuff. Forget templates for a while, forget >multiple inheritance (I once wrote a compiler, studied multiple >inheritance, then forgot about it for ever more, since it is SO >complex to implement, it can lead only to bugs). > >But if you do do single inheritance, use a virtual destructor in your >base class. Remember that. :)

Ok.. LaMothe says the same thing in his book... Over and over :0) Otherwise you don't deallocate the memory and get leaks, right? (among a million other GPF inducing reasons, probably.)

Quoted text (12 lines)

>> Thanks for the tip.. I just tried this as suggested, and it looks the >same >>still :-( Perhaps slightly better at times maybe, but the seams are still >>visible.. Jim Seamus said something about switching clamping on and off >during >>rendering, you know anything about that? > >That was what I was talking about. Basically repeating (as you did >before) means just chopping of the integer part and using the decimal >part for the coordinates. Near the edges, it will wrap, which you >don't want, but you want it to clamp instead, so 1.001 would become >1.0, instead of 0.001.

Actually, I just turned the MAG/MIN_?? filters to GL_LINEAR for the skies. That got rid of the seams pretty much entirely, save for an occasional flash. I'll have to mess more with that to get it working as you and Jim described.

Quoted text (7 lines)

>DX and OpenGL are largely the same, DX just came about 10 years later >and took 8 versions to get up to speed. :) >After knowing OpenGL, reading a D3D book will almost get you started >on OpenGL things as well, since most parameters look the same, it's >just with D3D you have to type 2x or 3x more to get the same thing >done. And don't forget that for DX9 you'll have a ball converting your >stuff to the new API. ;-)

Oh brother.... lol >#define GL_CLAMP_TO_EDGE 0x812F > >I'm sure though you cannot just use this, even if it might work. >There's an extension you have to check for. > Thanks.. I'll keep it around just in case.

Quoted text (9 lines)

>> (Converted to PowerBasic, so maybe everything's not there.) Don't look >>too hard, I want to see if there's another way to fix this. My road >textures >>don't have this problem. > >Since you created the dots yourself, why not do a triangle strip (if >you're not already doing so)? That will ensure you have correctly >shared vertex data. >

Ok, I'll try that. Should be a touch faster than quads anyway, right? Still, it seems to me that my quads would share vertices the same way, since they're defined two vertices at a time...

Quoted text (21 lines)

>> The quake style engine sounds awesome... I'm just trying to draw basic >stuff >>at this point! LOL > >It's really quite simple in fact; the basic problems are just twofold; >one is creating a shader sort key from the shader's properties, and >the other is making good use of multitexturing when possible. >Basically you have: >struct RenderData >{ > float *vertexData; > float *normalData; > //etc > int sortkey; >}; >You put everything you want to draw in a big list, quicksort on >sortkey, then render in passes. The passes are walked piece by piece, >and only flushed when a pass can't be added to the previous pass. > >Works for Quake. :) >

Man, I've got to catch up on data structures! lol Can you believe I don't use ANY user defined types or unions in my stuff? I've saved all this, will have to come back to it when my brain catches up to this point. :-P Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

On 28 Jan 2002 14:18:08 GMT, [email hidden] (J. Todd Wasson) wrote: ... > What I'm doing is scanning for nothing but INDI and VERT chunks. Being a >rookie, I actually scan the file four times when loading it (slooowwww.....) I would suggest that you use the chunk length to seek onto the next chunk, but I won't; there are some old DOF files out there that have bad chunk lengths for one of those ID's (GOB1 probably, being the most problematic one). Anyway, after 1 pass it should be in the cache anyway, so it shouldn't be that bad; although MS-Word seems to take a LONG time loading just a 1K .cpp file. :( (but that's MS-Word; I have absolutely no respect for Windows' caching scheme; when playing a game which requires a lot of memory, my swap file grows; when letting it sit and do nothing all night, the next day it didn't take the chance to clean up some of its swap mess, sigh). >First pass is to find the number of INDI chunks. Second pass loads all those >indicies, making sure to set them back to 0 (or 1?) at each chunk. Once I did >that, some of the little test models with more than one INDI chunk would >actually load correctly. The third pass finds the total number of VERT chunks, >and the fourth loads the vertices the same basic way. Should be ok, if every VERT chunk is tied to the preceeding/postceeding INDI chunk. Printing out counts would give you an idea why less polygons are painted than you expect (btw Modeler will give you the #polygons with 'Information'). ... > Oh, ok.. Maybe it's something I can learn then (although I doubt I could >write a compiler!!! Geeze...lol) I look at the C++ primer in Lamothe's "Tricks >of the Windows Game Programming Gurus" from time to time to get the (very) >basic gist of things in my head. I'm just messing with pointers now for the >first time. Pointers are nice but are also the source of why Pascal programs generally crash less than C programs. It's so easy to have a pointer to garbage. :) > Maybe after getting a better grip of those along with data >structures and such, I could move on to C++. Maybe.... Just maybe ;-) There's no life without pointers (well, references are nice and can avoid pointers, but to grasp that you need to be acquainted with pointers). >>But if you do do single inheritance, use a virtual destructor in your >>base class. Remember that. :) > >Ok.. LaMothe says the same thing in his book... Over and over :0) Otherwise >you don't deallocate the memory and get leaks, right? (among a million other >GPF inducing reasons, probably.) A memory leak is no reason for a GPF, and memory IS deallocated (well, the original class' memory), it's just that the destructor of the base class(es) isn't called, like: class A { void *p; public: A(){ p=allocate_1Mb_chunk(); } ~A(){ free(p); }; class B: public A { B(){ } ~B(); } Then if you do: B *pB=new B(); delete pB; Then ~A() won't be called; so you're left with unfreed memory in this case (p). And sometimes worse is when A() allocates other objects that do system-wide damage (opening DirectSound but not closing it on Win98 seems to be deadly). Getting a bit offtopic here. :) > Actually, I just turned the MAG/MIN_?? filters to GL_LINEAR for the skies. >That got rid of the seams pretty much entirely, save for an occasional flash. >I'll have to mess more with that to get it working as you and Jim described. Yes, use linear; nearest filtering just looks like it was software rendered; yugh! But wrapping should be turned of; use GL_CLAMP. At least, that's mostly how these skies are modeled; tiling different textures is quite a big field once you get into it; just try searching for 'clipmapping'.

Quoted text (7 lines)

>>Since you created the dots yourself, why not do a triangle strip (if >>you're not already doing so)? That will ensure you have correctly >>shared vertex data. > > Ok, I'll try that. Should be a touch faster than quads anyway, right? >Still, it seems to me that my quads would share vertices the same way, since >they're defined two vertices at a time...

Ah, it's a quad list? Then it's ok too. It's just quads get converted to tris anyway on today's cards.

Quoted text (7 lines)

>>struct RenderData >>{ >> float *vertexData; >> float *normalData; >> //etc >> int sortkey; >>};

... > Man, I've got to catch up on data structures! lol Can you believe I don't >use ANY user defined types or unions in my stuff? I've saved all this, will >have to come back to it when my brain catches up to this point. :-P Really, without these kinds of data structures it's like coding in assembly; everything is just a location somewhere. Only divide & conquer will help in reaching new heights in programming. Meaning data structures are essential for complex programming, which car sim programming obviously is, beyond RARS' force generation scheme (however wonderful). To stay ontopic; what a nice car just drove by! :) Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/