[b]Update week 17
[size=2]Viewer v12:
[/b]The viewer is as good as done! Hereās an email I got from Flavien about the status:
[/size]I have again found some materials that were not coherent, for example a diffuse assigned to the ānormal mapā chunk. Instead of getting back to you ( we could continue like that forever ), I prefered to review the engine code to detect those problems and assign ādefaultā textures when the existing ones are not complete or coherent.
Everything is pretty much done now. The instances are fine, the textures and the bump mapping are there⦠there are only two remaining things to do:
- Add some parameters for shadowing in the setup dialog.
- Re-export the whole model. Thatās basically the reason why it takes so long⦠at the moment, I donāt have 3 hours straight where I can monopolize my computer just to export everything again. Itās getting tricky too, because it takes too much memory at export time with a single .ASE file, so I have to split the whole model in 2 so that my 2GB of RAM are not exceeded.
Optionally, Iād also like to review the level of detail. I noticed some strange behavior on the props, with missing triangles even when youāre still close.
Last week, I fixed the physics problems. The random crashes were caused by some geometry that had degenerated triangles. Previously, I had a check to filter out those wrong triangles ( thatās really an art problem ), but in some cases, this filter didnāt work well enough. I reviewed the filtering code to gain precision in the calculations, and so far I havenāt been able to make it crash again.
I limited the velocity of objects ( character capsule and launched balls ) to avoid the ātunnelingā effect⦠you know, when you did the Denethor jump for example, you often ended up inside the rocks / under the ground.
Finally, I investigated the slowdown problems due to physics, and I came to the conclusion that many of the physical objects were not correctly placed in the initial state. The catapults, for example. The problem is, all physical objects are simulated by their bounding boxes, so although the catapult geometry doesnāt touch the walls, the bounding box penetrates inside those walls, and in turns it generates thousands of collisions contacts per frame. With tens of catapults, it gets bad quickly. I had no solution other than disabling catapults as physics objects.
The 2 statues at the first level, just in front of the rock ( behind the horse statue ) are not stable, because theyāre dropped on a base that isnāt flat, if you see what I mean. Iām not sure if itāll keep them as physics objects or not.
I came to realize that last time I exported the city, I accidentely checked the āgenerate tangentsā check-box in ASEToBin. Tangents are generated from normals and are necessary for bump/normal mapping. Where it went wrong is that I anyway generate those tangents at load time - so it doesnāt matter if those tangents are exported or not. However, they do waste memory ( since 99% of the buildings are not normal mapped, and donāt need tangents ), and they do waste hard drive space. Roughly 25% of the whole dataset can be saved by NOT exporting the normals. Thatās purely a v12 issue though, because as far as I remember, v11 didnāt have tangents exported.
Even better, I discovered a new way to generate normals at load time, without loosing quality or performance. Normals are still needed to perform lighting ( so they have to be in RAM - no gain in that area ), but they donāt have to be stored on the hard drive by the exporter. So I can save again 25% of the whole dataset. Hence another reason why I need to re-export the whole city.
I estimate that the .bin file on disk will be half smaller than in v11, despite the additional geometry from v12.
Website:
Emiel and I started working on the technical part of the new website. Due to some communication problems, Tim hasnāt started yet (we hadnāt sent him some required documents yet), but heāll be able to start very soon.
Emiel has been working on the basis of the core, and made a very nice sort of debugger/variable dump:


This way of error display can be toggled on/off easily, so itās very useful for the development phase, and it doesnāt require any modification once everything is set up.
And hereās a nice flowchart Emiel did for the theme engine, to illustrate how much everything is planned out:

So this is why the pre-production took rather long. But itās definitely going to help us in the production.
In the meantime, Iāve been working on an XML parser for the website, which reads an xml file and stores the data (including the structure) in an object. And the other way around too, so writing an xml file from an object. And Iāve also begun on scraping ācommonā functions like changing dates, time, array and string functions together. And Iāve also begun with the first components (a component is a āpredefinedā part of code, like for example an swf object)
[color=DarkOrange]Building models progress:
[color=#fffffe]Hereās an updated map with the progress coloured in:

Green : Completed
Yellow : Work in Progress
Red : Not started yet
Itās time to get working more on the models againā¦
[/color][/color]