Hi
That's not completely true... at least, one is reading your posts  ;)

Biterider
Posted on 2007-02-05 01:01:39 by Biterider
I'm reading them as well :)
Posted on 2007-02-05 01:02:58 by f0dder
you'v worked hard for the asmcommunity. this has been admired by everymember.
a few members understood the content of gamedev, at least to me.
Posted on 2007-02-05 01:28:57 by dcskm4200
Attachment contains update for Project A.
I've stripped most of the render-related code from this project.

I'll now turn my attention back to Project B and adjust it for the changes that have been made in the custom file format, node struct, etc.

Attachments:
Posted on 2007-02-06 04:07:30 by Homer
The XFile export plugin for Maya 6.5 (that ships with the December '06 DX9 sdk) is definitely borked.
Minor gripe : You can't choose to export in Binary X format, it exports as Plaintext X format by default, forcing you (wink) to use another tool to convert them to binary if you so wished.
Issue : Without my knowledge, the vertex format for an untextured (colored) lit vertex had been expanded to SIXTY BYTES PER VERTEX.
Worse, the mesh will load, but GetFVF() returns NULL, which is simply wrong.. then my CrackFVF functions tell us lies because dwFVF is NULL...What the heck ??
Since the file format is plaintext, I looked to find out what the deal was.
After the mesh data, I saw a huge block of per-vertex user data.
I stripped the whole block, and the problem disappeared.
GetFVF() was now returning sane values once more, and we'd shrunk the size of the xfile by a bit under half, and our custom file also (since vertices were no longer so insanely big).
Posted on 2007-02-07 05:55:07 by Homer
I've corrected some more minor bugs in the Saver and Load functions, and reworked the file format.. the worst bug was that the Octant BoundingBoxes were not being calculated for nodes whose faces had been 100% sorted into childs and thus were devoid of Faces.. this meant that after Generating the Octree, we could not navigate it by using 'the fast Octant test' (which needs the BBox origins..)
Another one known bug to fix before I repost both project sources, then it will finally be time to write some NAIVE rendering code (just as a safety check to make sure everything is groovy), followed by CULLED rendering based on our 'OctoSphereTree'.

The culling algorithm itself is very typical and so if you're a student of this kind of code then you won't be shocked or amazed, however you'll appreciate that we've vastly accelerated the test at each Node.
Posted on 2007-02-13 23:16:21 by Homer
Attached : updates of both relevant Projects.

The input xfiles I've included have been stripped of the weird fat I mentioned.. they dropped by about 30% in size.
Due to the vertex size also decreasing, the size of the output 'bla' files is reduced by something like 40%.

We have crude rendering code for a demo Quad..
We'll need to add just a little code to create a VB and IB for each Node, then add crude rendering code for a Node's faces..

Posted on 2007-02-14 06:04:16 by Homer
This update contains additional code in the LoadNode function.
Each node now owns its own VB and IB, which have been set up as 'write-only' to make them a little faster.. we have a duplicate of these data blocks in each node, so we don't actually need read access.
LoadNode will allocate a VB and IB for each node that has Faces, and will copy the data into them, ready for rendering.

The update contains no code for rendering, that's next!!
Attachments:
Posted on 2007-02-14 07:29:12 by Homer
This update of Project A (Generator) contains some refinement to the code involved with the 'per-material face grouping info' that we store in our custom file (see the end of SaveNode function).
This new format assists in rendering (Project B).
Our Loader/Renderer now has a quick and clean way of determining the start and end of per-material face subsets during rendering, so the render code won't need to calculate that kinda stuff at runtime.

Note : my demo xfiles only contain one Material, but we can expect that the World will use MANY Materials, so its important that we support multi materials right from the start..
I've gone further and supported FVF, so later we might be able to have more than one OCTREE being rendered and culled against the Frustum, and the vertices of each OCTREE can be totally different formats.
Our Octree format doesn't support multiple FVFs, but we can certainly support multi-Octrees with different FVFs :)

We can now improve the Loader so that it loads the facegrouping info into a heapmem object, or with some small effort into one flat array, instead of an oa32 collection object, but we'll leave that until after we get the rendering working :)
Attachments:
Posted on 2007-02-17 20:57:02 by Homer
sorry been busy modelling, my new avatar is a tribute to OOPASM
Posted on 2007-02-25 14:19:04 by daydreamer