Quote:
OBJ files are 'compressed' by listing all of the common vertices in the v section, the common normals in the vn section, and the common uvs in the vt section. The faces (f) section then links all of these together to create vertices. There is hardly ever a 1:1 ratio between all of these (3DS Max can export to a 1:1 ratio). In your 3D modeling program you have a geometry visible on the screen. Each vertice that you see on the screen may actually be multiple vertices. Why multiple vertices? Might have 2 or more textures at that same point (thus needing 2+ unique sets of uvs). When you export this geometry that's visible the app will see that their are vertices that have the same positional data but different uv data. The app will export just one vertice (v) but 2 uvs (vt). If the normals are different between those vertices then it will export 2 normals (vn). Here is why I said OBJ files are 'compressed' earlier. My app is now smart enough when reading in OBJ files to see that their are 2+ uvs (vt) referencing the same vertice (v) and thus will create clone(s) of the vertice (v) to properly render the geometry. Clicking the Calculate button will have the app recompute the binormals and tangents of the currently selected mesh (if it has either/both). It appears to do nothing but it does do something :up: |
Quote:
Quote:
|
Quote:
Yes tangents and binormals are calculated automatically each time a new mesh is imported (if they are in the vertex declaration). That button is there to force the calculation (such as on SH5's GR2s). I haven't finished this feature yet but I'm coding in the ability to modify a vertex's normal with the app (using the mouse). You select the vertex and turn on display normals. Then if you grab the end of the normal you can move it with the mouse. This will allow fine tuning of the normals :up: Then after you modify the normal the app will have to calculate the new binormal and tangent since they are based on the normal. |
Quote:
Quote:
|
v1.1.434.1 released. See post #1
- Fixed memory leaks found - More optimizations done to decrease loading/save time - everything else mentioned in the previous posts since last version was released |
Quote:
|
Amazing :sunny: Thank you
Quote:
|
Quote:
Before I would read everything sequentially and in sequential order. For instance: read all Textures and read each texture of those Textures one at a time. When done reading Textures then read all Materials reading each one at a time. That worked ok but loading times were really lousy. Now I still read everything sequentially (Textures then Materials then ...) but in each section (Textures, Materials, etc.) I spawn off additional threads equal to the number of items in the section thus achieving a parallel read of all the items of the section. I did this for the PrimaryVertexData and the Meshes so far and the results are excellent :D Loading the Bunker.GR2 on my home system takes ~11.3 seconds using the old method. Using the multi-threaded method reduced the loading time to ~8.0 seconds. That's a 30% reduction in loading time :yeah: I have an 8 core AMD processor so the total number of concurrent threads (that's ALL threads currently defined in the OS) that can be running at any time is 8 (even though 40 threads are spawned when the PrimaryVertexData is read in a max of 8 will be 'running' at any time.) . The more CPUs and the more cores each CPU has then the lower the loading time will be. Intel processors will have a much faster loading time due to their hyper-threading (they can run more than 1 thread per core on each processor and they have a higher IPC than AMD). Now I haven't even done any optimizations on the multi-threading yet (like having the PrimaryVertexData spawn additional threads for the vertices). This was just a trial run to see if I finally fixed the multi-threaded problem I was having a long time ago. |
increasing the performance of the GR2 Editor :sunny::yeah: Very good
Quote:
|
Hi there, please can you tell me how to zoom this mesh/texture view of the tower ?, thank you :up:
http://i194.photobucket.com/albums/z...ps1b20f5b9.png |
Quote:
You'll see that if you right click and hold and move the mouse forward/backward you can zoom. You can also use the arrows on the numpad to 'walk' fwd/bckwd/left/right. |
Hi TDW,
how hard would be the (temporary) merging of two GR2 files in your application? I make myself clear: one of the major differences among SHIII-IV sea units and SH5 ones, is that most general effects are linked to the bones of a second GR2 file (*_FX.GR2) which gets "overlayed" in game to the main GR2 file. By looking into several *_FX.GR2 files, I have noticed that their bones follow roughly the profile of the model they apply to. Should we create a new GR2 ship, we would be forced to move her FX nodes blindly though. The task would be much easier if we could preview the 3d model (of the main GR2 file) over the nodes (of her FX GR2). :hmmm: |
Quote:
You can see this effect when loading any player's sub (if the options are set to do it) :up: |
Quote:
|
Quote:
|
All times are GMT -5. The time now is 12:09 AM. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright © 1995- 2024 Subsim®
"Subsim" is a registered trademark, all rights reserved.