Hey Homer

Well it works now but I assume the entire map is supposed to be textured. The patch we start above is textured but the rest are either a solid color or striped. There's also something fishy going on with the edges of the starting patch which looks like texture clamping, I think that's the right name? If you could add the ability to take screenshots I could show you what I mean.

It took approx 37secs to generate the textures so I don't know whats going on here compared to your 6.5sec. What type of computer do you have roticv?

The mouse also feels a bit sluggy but the app runs at about 130FPS.
Posted on 2004-03-11 16:13:13 by Maelstrom
You should NOT need the original download - this Beta.zip is continually updated at the original link.
Todays changes (not yet uploaded): more robust codebase, detection of which terrainpatch the player is above was moved outside of CTerrainPatch class and into the Render loop, and code to detect the exact triangle that the player (camera) is above was also added and implemented, with a view to fast player/terrain collision detection.
Also, you can now delete any selected "boxes" that you have dropped as a group by hitting the BACKSPACE key (with the arrow on it), with the exception of the "Reference Object" - currently you cannot delete that.
Posted on 2004-03-12 00:42:14 by Homer
Hey Homer

I downloaded and extracted the latest Beta.zip, but it went down in flames when I ran it. I then downloaded and extracted NewD3D.zip, extracted Beta.zip over top of that, now it runs but the terrain is messed up. Have I stuffed up?

This is what I see!
Posted on 2004-03-12 01:42:02 by Maelstrom
Wow hehe - what a cool stuffup :)
You should not have needed to extract anything over Beta.zip, when you extracted the files from Beta.zip did you get 3 folders?
All the files in Beta.zip contain paths already, but if you extract from the zip all the files to a folder manually you lose the paths.
The solution is to let Zip create a folder and extract the files, you tell it the path of the new folder.
As for the result you got, I'm at a loss to explain it - I have yet again hardened the texture Creation code and will repost the Zip soon - right now I'm trying to implement the cheapest possible player/terrain collision detection I can.
Posted on 2004-03-12 08:45:02 by Homer
Hey Homer

Actually I extracted Beta.zip on top of NewD3D.zip.

I have 3 folders, Maps, Objects, and Textures. I'll delete everything and try again with your next Beta.zip.
Posted on 2004-03-12 16:06:50 by Maelstrom
Just a brief progress report:
I got tired of working with the Terrain Collision code, so I took a break and went back to playing with my CSkinMesh code. I spent a couple of hours tracing a bug, and when I finally tracked it down and crushed it, it felt good. It was a silly bug too.
That being said, I expect to spend more time on the skinmesh side of things in the coming days, as I am anxious to see animated thingies on my terrain (who doesn't love animated thingies?)
I keep thinking about what a mess the Object Render Loop is, and how I could minimize texture swapping while at the same time still take advantage of the inherent mesh face subset-sorting. What seems most logical to me at the moment is to construct lists of renderables underneath our list of Reference Textures... This means each unique Texture owns a list of things that in fact use that texture: more precisely, we'd have to keep a struct which contains a pointer to the object instance, and a fastlookup pointer to the specific Material of that object which uses said Texture.
By keeping this information, we can now render all parts of all objects by texture, and totally eliminate texture swapping.
Better yet, if we implement this apon a lower class like CMesh, then it applies to any and all higher classes (like CBullet and CCullableThing, or my latest, CDoor).

Doors turned out to be well worth encapsulating in their own class, since games can use a lot of them, and they can all have their own State.
My Doors have 4 States:
-Closed
-Opening
-Open
-Closing
My Doors have a field called "Current" which is the rotation of the door on its hinges, from 0 (closed) to + or - 90 degrees, expressed as usual in radians (pi/2=90degrees)
I have not yet found any reason to create any class functions for CDoor, I can't justify the overhead. I have learned to be more judicious in my use of OOP and to respect that there is a place for everything.
"So why not just make CDoor a struct?" you may be thinking..
the reason why is that we can (and do) inherit from lower classes like CMesh, gaining the ability to load different meshes for different doors, scale doors using scaling matrices, use the CCullableThing collision code to detect when we just busted our nose running into a door, etc.
Posted on 2004-03-13 09:14:31 by Homer
Today I think I have decided to keep a copy of the extracted per-terrainpatch Height data within each instance of CTerrainPatch, the arrays are not large, and theres a very good reason to keep them - the best reason is that it eliminates the need to Lock terrainpatch vertexbuffers for the purposes of collision detection math, but another good reason is that it eliminates one of the two pixel lookups in the terrain building code, which should speed that code up considerably :)
I went around to a friend's place last nite and we ran the old beta (he runs an intel 866) and we got terrain build times of just under 40 seconds ... it appears that my fpu code in the terrain texture blender is very unfriendly to intel processors :) I'll probably implement cpu detection and casecode at a later date, since I find the performance on intel based machines totally unacceptable :(
Posted on 2004-03-15 05:02:06 by Homer
managed to get it up to 234fps (looking in to center sitting on an edge), 5000second for making textures on my machine, minimum 155fps (starting point, probably in the middle of terrain), geforce5600 amd2400,400mhz memory
it looks very nice, but I feel very myopic running it cant you give the option to how far you see, you need to implement a mouseinterface that uses relative movement, otherwise when mouse is full left or right, it feels like a invisible wall is stopping me to turn any further
blending textures sounds awfully slow, isnt it faster using integers for blending textures?
DD
Posted on 2004-03-15 12:22:25 by daydreamer
Thanks very much for the feedback, keep it coming :)
You are running the same (older) version of the Beta that everyone else is, and get similar terrain build time and fps to me, what is your hardware? AMD based cpu?
Sorry about the mouse filtering, it was an experiment I was conducting with Ultrano, I'll remove the mousefiltering entirely, which will make "mouse looking" as stiff as motion currently is.
Right now I'm still playing around with CSkinMesh trying to just get something to render at all :( This is officially my third attempt at implementing animated skinmesh, but the first oop attempt - the earlier two attempts were "completely oopless" (forgive my pun), and worse than that, did not support hardware vertex blending.. the current version is totally based on the sdk example from DX8.
I am also working stoically on several implementations of terrain/player collision detection code to find what works best...
My next milestone will be nothing more exciting than having the Camera follow the Terrain, followed by a version which shows the player mesh in third person.. while implementing these, I will continue hard at work on CSkinMesh because I insist on using an animated mesh as the player model.

Regarding the "invisible wall", keep an eye on the Mouse Cursor (arrow) while you run the Demo - the Wall you hit was the mouse hitting the destop bounds.
I really need to rework my camera code - at the moment, the viewing direction is calculated from the mouse XY coordinates.

As far as in-game editing is concerned, this is very natural and easy to use - you can actually rightclick on world objects using the mousecursor to select them.
It is totally unsuitable for use in an actual game however, I'd be better to read the CHANGE in mouse position and keep forcing the mousecursor back to center.
Posted on 2004-03-15 21:47:33 by Homer
amd xp2400,512mb DDR400 running 400mmhz bus, geforce fx 5600 128mbvram, 8xagp, agpfastwrite enabled etc
I saw that afterwards with the invisible wall, was just concentrating on steering and hope you keep that fast rotating, using DI dx,dy, turn off mousecursor
moving should be done with keydown increases speed until reached maxspeed and when key is released, decrease speed to zero slowly(depending on what the player is controlling), add the different speedvectors in mainthread to position
measure ms between frames, and multiply the time that went before last frame with speed to make it speed-indepentend of framerate
Posted on 2004-03-17 13:19:17 by daydreamer
Yep, I totally agree, physics should be applied to player motion - in fact, the mousefiltering you saw was a cheap attempt at cheap physics. Real physics will come soon, but I saw little point in implementing the physics code until (A) I had something to collide with (which we now have) and (B) code in place to detect the collision (since the feedback of the collision affects the physics too).
I've been a little carried away with getting SkinMesh working again, but I have not been idle.. I have begun implementing some SEH code to trap and handle bugs (as a further aid to debugging more than anything else), I'm checking for and handling more errors than ever, I've begun redesigning the internal database to accomodate a client/server topology and I have finally decided how to implement as cheaply as possible the terrain collision detection code - albeit yet to implement it. I realized that since my terrain heighmapping still only alters the vertex Y coordinates, I could use that to my advantage to reduce the set of surfaces to test for collisions by very quickly identifying the closest surface(s) to a given point in space :) More to come soon, sorry still have not updated Beta, please bear with me, I see little point in making daily updates if there's nothing majorly improved.
Posted on 2004-03-21 08:09:40 by Homer