Today i was adding XWall or well barriers to the map. i've ran into some issues with transforms but thanks to observation i've been able to tell a chatbot how to condition the script to export stuff those were the issues as you can see the transforms were not showing up so the script couldn't pick them up. After some tiresome loading and reloading of the map which takes 5 minutes each time i got it to work If these fences were correctly aligned then some other objects would be messed up. Fix was checking the rotation values as some needed to be flipped and i found a pattern where some are close to 180 and some to 0 and they just needed to be flipped accordingly. Now all XWu objects are set correctly. These are static objects in Carbon which means they are not smackable. They need a collision mesh but i'm not bothering with that at the moment but bounds can work really well for collision as most are box shaped Some objects still appear a little wrong but i don't know if its related to shearing used by bbx on their stuff
View attachment 1287139 View attachment 1287137 View attachment 1287138 those were the issues as you can see the transforms were not showing up so the script couldn't pick them up. After some tiresome loading and reloading of the map which takes 5 minutes each time i got it to work View attachment 1287140 If these fences were correctly aligned then some other objects would be messed up. Fix was checking the rotation values as some needed to be flipped and i found a pattern where some are close to 180 and some to 0 and they just needed to be flipped accordingly. Now all XWu objects are set correctly. These are static objects in Carbon which means they are not smackable. They need a collision mesh but i'm not bothering with that at the moment but bounds can work really well for collision as most are box shaped Some objects still appear a little wrong but i don't know if its related to shearing used by bbx on their stuff View attachment 1287148 View attachment 1287151 [/QUOTE] there is an issue: Look at the trasnforms. You can also see the fence at top left is aligned differently. I export a rotation matrix based on blender world matrix to xyz then converted back to rotation matrix, flipping Y and Z rotation values when necessary to maintain correct positioning This makes objects aligned to the road in some cases be incorrectly aligned to the road, making them "jagged" and therefore wrongly positioned. The shearing bbx used is not the issue. I'd greatly appreciate help in this issue This issue also occurs in stuff that leads down a bowed path: this one is okay here and in blender this one isn't But others are just fine: The shearing bbx used is not the issue. I'd greatly appreciate help in this issue
Issue has been resolved. Correct spline like curves are in game. Issue was in how i was moving coordinates from one place to another in a very hacky way (it's still one! but it works now) More of them. As issue has been resolved i think i can add the rest of the objects with this script. It should be robust enough as it is moving coordinates appropriately to how BeamNG expects them, or so it seems. That's what i have for today
Today i added the rest of the map. Some rotation issues still exist with xtu objects so far but it seems to be i'll have to fix those manually. Also some poles and stuff share the same issue mostly on canyons. A big issue currently is loading time (for me it takes near to half an hour to load) which i'm trying to pinpoint but the console dies at loading time so i'll see if the logs do something there. I'm adjusting object properties as of now (collision) to see if the computing of a visible mesh as collision is making that issue There are like 160k instances in total and around 29k meshes. The meshes are kilobytes in size most of the time but the size of the map is comparable to the STREAML5RA.BUN file from carbon as after all it's the same thing I'll update this post for pictures of how the map looks today
no. i'll update the posts later and I'll attach the updated test version at night. sorry for any confusion. I have already updated the main post with the latest version's issues
love it gonna try it out today evening hope it runs better then before were i was stuck with like 20 fps cause i love the Carbon Map u made the Objects that u can normaly run over in Carbon without a hitbox right? so we can just drive thru
Everything is drive through because of current version's issues. Roads and terrain are the only two object classes that have collision.
The following update is focusing on joining these meshes for Terrain and Roads. This should reduce the load on loading tiny meshes for what can probably cause negative performance on computers like mine. This is an example. The CHOP is a piece of the map conforming to the Scenery Section the object is confined within: nfs maps have sections from ABCDEFG whatever with a number after the letter. This image shows it. For example, undercover alpha 65 i reviewed a few years back See in the info tab at the bottom, right below Race Now, the coordinates. The D42 number is current section (CHOP) number. That is the reference for the game to load off the stream file in full detail. As this map doesn't use sections, they are pointless (and the game isn't also using a stream system; so even more pointless) to have as many meshes. This optimization should help quite a lot. It also helps with the game calculating the distance from the camera required to load the section. Small meshes fall through as very small objects, breaking the "nulldetail" setting. This should fix that and make the requirement to use Zeit's graphics obsolete and made so it is optional if one wishes to extend draw distance only. LODs for objects are not redundant and I have them after exporting all objects but looking for a lod of a mesh is quite boring. I'll probably do that after basic meshes are fully corrected (roads and terrain) as they would be the next step towards polishing up the map. Along with the XWu objects fix. Object joining is done! Roads was 3K Terrain was 7K SpecialTerrain was 12K. around 7k difference in meshes. Should yield a sizeable improvement. Results of the merging: 18k meshes less for the game to load 154.21073|D|LoadingManager| Loaded 128845x Meshes::TSStatic in 98.823s (0.001s each; 98.823s total so far in this category) was 1440secs. improvement ! These changes have helped computers like mine (reference: my computer ) Map is more stable now and ram usage seems to have decreased. Drawcalls should have been reduced too! It looks a win situation. Could it be better? I don't know. I think i am yet to merge vertices by distance but i don't think that can do a sizeable performance optimization. That'll be all for today. PBR conversion post will come tomorrow. Dry roads! I don't like overly reflective roads. They look greasy at low settings and too watery at high settings.
Onto the matter of PBR conversion, a big thing is consistency in material looks. Fortunately, carbon presents a very easy way to change their looks. Road textures are half alpha and in the process of converting to pbr, I extract opacity maps; the opacity maps for roads are nothing more than the specular factor used when the game has rain. Thus, roughness has to be made the opacity map if one wishes the rainy look. Otherwise, manually created roughness maps look dry and make road markings look decent The WDIAL selected is using the opacity map as a demonstration. The roads to the left of the WDIAL are using the PBR maps. The consolidation of CHOPs from meshes reduced drawcalls and opened me an opportunity to not worry a lot about drawcalls for roads so you may expect detailed roads. Not on the resolution side though. I can't upscale the roads efficiently enough, and the artifacts created by said process outweigh the possible benefits. I've already upscaled them before, in fact. Some 2023 build in this thread probably contains my upscaled textures. This image has the correct map. Some inconsistency in concrete roughness due to no wear markings on the texture. Some water has also been added. Water crossed over to this road. This road uses the opacity maps (rainy specular factor in nfsc). This will not be default behavior. Currently the conversion will cover roads and terrain. Buildings are to come later. New update will release after partial PBR conversion and fixed XWu collisions i ATTAch more images below:
It seems it might be a problem with the amount of objects on load. On the 10th of March an update will be released fixing that issue Today i fixed the object rotation issue for all objects: Kings Park Before: After: Most if not all of the issues have been fixed. Now no more zeit's graphics are needed for normal gameplay! LOD Scale is now good at 2 (what Ultra Mesh Quality equals to in this value) and lower quality levels scale appropriately. this required a reexport of the meshes but was worth it. Now i'm trying out a way to dynamically calculate the correct values for both nulldetail and the _axxx in the name of the empties to have smooth unloading without having small, instanced object disappear too close to the player and thus making big objects unload better so the polycount and drawcalls are further reduced and the overall performance is better. also i've been trying out the unloading of meshes to have other environments other than the city display correctly. This issue might make next update be missing the canyons and san juan but it depends on how much i can do before next tuesday. Materials also need to be finished you might notice blocky trees i haven't applied opacity maps to those that is all for today
So i accidentally deleted the materials.json file (and i shift+del so it gets deleted instantly, tried my data recovery stuff but it was overwritten when the game recreated the file) but well. The mesh dynamic nulldetail and _a# is in now along with autobillboards for XTu objects. While more adjustments can be made, i think i've reached a happy medium. Little tiny props are now disappearing correctly not in front of the player and i have a new friend i didn't see at all before: the XOU_CatsEye_Orange_00. It is a tiny mesh so every other export, the mesh was there, being instanced, but not visible to the player. This update fixes it i guess. Also, no more laggy skid decal rendering causing fps to drop as every mesh now has its Colmesh-1 assigned. I'll do materials now after i recover some meshes from separating the canyons. This update will have no canyons unless i fix the sorting on my blender collections. Be aware, the creation of autobillboards does extend the loading time by a little bit on the first launch but then they're cached and ready for every launch. Performance seems even better now. My computer is now doing 5 fps more (keeping in mind my computer can't run WCUSA at more than 15 fps with my current settings). I'm averaging 20-25 FPS driving. On the first release version i was running 9-12fps while driving and 15 doing my camera pan around roads performance test so performance will be better for the end user (i'm GPU bound according to the Performance Graph and according to common sense too). If I can't fix my blender file organization i'll have to release the update tomorrow but i'm confident i can at least get the whole city back again before sunset. From the first try on this, objects were rendering way too far from the player and using excessive drawcalls. The Colmesh is currently the object, duplicated and renamed. This is supposed to be a temporary fix but i don't think i'll be changing it soon. Now the little tiny objects do render further away from the camera and farther away objects are billboarded for XTu and the rest are just unloaded when the pixel threshold is reached. Minivan for scale
