Product Chat / Models Scaling after baking light maps

Author
Message
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 2nd Apr 2016 00:14
Quote: "I was not aware of a second UV layer in the supply crate geometry. Does anyone have the skills to drill into this X model and let me know if there is a second UV layer on the geometry or a second polygon overlapping the primary ones which could also cause the issue observed. Thanks all!"


Let me clarify, I was not stating that the model had a second UV layer. When I test the light mapper I can only get it to light map a model correctly that does not have any overlapping geometry in the UV atlas of the object. In the discussion above it was suggested that this was not the problem because they believed GG's Light mapper unwraps the objects and creates a new UV atlas without overlapping geometry. Then uses this new UV atlas to create a second UV layer for the object to be used for the light map. Lee is this assumption correct? If it is, why does only models without overlapping UV's work correctly?

I had assumed that the way the light mapper worked was that it used the DirectX UV atlas tool to create a new UV atlas for the object and then created a second UV layer for the object which would then be used for light map texture. My test results seem to suggest that this is not the case. Lee can you clarify how the light mapper works?



The coffee is lovely dark and deep,and I have code to write before I sleep.
rolfy
18
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 2nd Apr 2016 01:17 Edited at: 2nd Apr 2016 01:44
Quote: "Then uses this new UV atlas to create a second UV layer for the object to be used for the light map. Lee is this assumption correct? If it is, why does only models without overlapping UV's work correctly?"
Most of the stock models have overlapping uv's and work just fine. Seems like you are only going by the models that don't work. As for clarification that a second uv layer is created you described it yourself in the second paragraph above so I think you know the answer.

If you build a standalone and delete the dbo files in lightmap folder you will lose all lightmapping in the level, I really don't think it is an assumption that a second uv layer is created.

I don't have any answer as to why it works better if you give uv islands their own space perhaps the lightmapper gets less confused if you do this. All the same as I described this particular model should be separate LOD levels and it isn't being a single mesh. So I think that may be the problem as many models with overlapping uv's and LOD levels work perfectly where this one doesn't. The lightmapper should only use the highest LOD for this and is being forced to pack in all of the levels since they are a single model.
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 2nd Apr 2016 03:23
Ok, So it would seem that we have now narrowed it down to a problem with the LOD meshes not being separate.
Could this possibly be handled by the light mapper?
The coffee is lovely dark and deep,and I have code to write before I sleep.
rolfy
18
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 2nd Apr 2016 03:28 Edited at: 2nd Apr 2016 03:28
I reckon it would be best to fix the model, if you have noticed others you should list them so they can be checked out. It isn't something you would want to be fixing yourself as a user so I completely agree with you on that point.
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 2nd Apr 2016 17:11
Lee can you confirm the issue is with the LOD meshes?
The coffee is lovely dark and deep,and I have code to write before I sleep.
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 3rd Apr 2016 17:32
After some more testing I can confirm that if I remove the LODs from the model and leave the high poly
mesh the model will light map better but not 100% correct. The model I am testing is the SupplyDropV1.x.
I then noticed that the smoothing groups for the model are not correct for either light mapping or the real time lighting.
I fixed the smoothing groups which may also be referred to as hard and soft edges in some modeling programs.
In other words I corrected the normals so the model will be light correctly by DirectX rendering.

In the screen shots the LOD's have been removed and one model has the normals corrected while the other does not.
One screen shot shows light mapping and the other real time lighting. It is easy to see which one looks correct.

In conclusion it would seem that GG should not be light mapping all the LOD's or the models should be made different
so GG does not need to handle it. Also the models should have proper smoothing groups so that they render correctly
with DirectX Rendering. I think there needs to be a higher standard that models must meet which would improve the overall
appearance of GG. A lot of the default media and DLC's suffer this dilemma.
The coffee is lovely dark and deep,and I have code to write before I sleep.

Attachments

Login to view attachments
rolfy
18
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 3rd Apr 2016 20:20 Edited at: 3rd Apr 2016 20:28
It is a bit of both really Artists need to ensure that they create LOD correctly, as for the smoothing groups issue it has been known from the start that GG lightmapper is horrible with these, Errant mentioned it way back. The lightmapper really needs some attention and a thorough testing but for both users and Dev's it has been a case of 'good enough' for now. I am sure it will be sorted in the end but only if enough users push for it. It is good that some users dig deep enough to find the cause of issues, but for the majority they either don't use it or find it good enough for their needs without realizing it isn't entirely working as it should.

When the building editor is done and you see more interiors requiring lightmapping is when you will see others stepping up to point all this out.
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 3rd Apr 2016 20:42 Edited at: 3rd Apr 2016 20:49
So , far my testing shows the real time lighting and the light mapper work correctly if the smoothing groups are good.
It seems that the SupplyDropV1.x model has good smoothing groups on the high poly LOD which works correctly with the real time lighting.
I inadvertently caused it to loose its correct smoothing groups when importing into Fragmotion to separate the LODs into separate meshes.
I did notice that the smoothing groups on the lower LODs were poorly done which causes them to render lighting incorrectly.

My final conclusion is that GG's light mapper and real time lighting are working properly.
If the light mapper can account for the LODs collapsed into one mesh then the models would not need repair.
But this might not be possible to do automatically in GG for all models.

P.S. Is there a special setting in a FPE file for a model with LODs?
Does GG create .bin files for models anymore or was that changed?
The coffee is lovely dark and deep,and I have code to write before I sleep.
3com
10
Years of Service
User Offline
Joined: 18th May 2014
Location: Catalonia
Posted: 3rd Apr 2016 21:11
AFAIk

Quote: ";LOD System
disablebatch = 1
lod1distance = 200
lod2distance = 350
lod3distance = 450"


And nor, just DBO files.

3com
Laptop: Lenovo - Intel(R) Celeron(R) CPU 1005M @ 1.90GHz

OS: Windows 10 (64) - Ram: 4 gb - Hd: 283 gb - Video card: Intel(R) HD Graphics

PM
rolfy
18
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 3rd Apr 2016 21:20 Edited at: 3rd Apr 2016 21:30
Quote: "If the light mapper can account for the LODs collapsed into one mesh then the models would not need repair.
But this might not be possible to do automatically in GG for all models."
If collapsed to single mesh then there is no way for code to separate again and it is treated as one mesh, it could simply be that LOD levels are named wrongly which would also force all LOD levels to be crammed into a single lightmap.

Since I was unable to even select sub objects (only faces) it may be that I have missed an import option myself and collapsed the mesh in error just like you did with the smoothing groups
Can you see what each LOD mesh has been named after import to Fragmotion? If so it may give an idea of what went wrong with this particular model.

3com, those fpe settings are for distance LOD's are changed, they don't affect the mesh in any way. You don't even need them if using the default distances they are useful to change when you have a very large or small object where the default distances don't fit too well such as a large building which won't change to highest LOD because you never get close enough because measured from the pivot or a very small object which should use lowest LOD till right up close where it can be seen.
3com
10
Years of Service
User Offline
Joined: 18th May 2014
Location: Catalonia
Posted: 3rd Apr 2016 21:27
So, I missunderstood Stab question here
Quote: "Is there a special setting in a FPE file for a model with LODs?"


3com
Laptop: Lenovo - Intel(R) Celeron(R) CPU 1005M @ 1.90GHz

OS: Windows 10 (64) - Ram: 4 gb - Hd: 283 gb - Video card: Intel(R) HD Graphics

PM
3com
10
Years of Service
User Offline
Joined: 18th May 2014
Location: Catalonia
Posted: 3rd Apr 2016 21:32
I must admit I never mind in smallest ones, just about largues; great info Rolfy, thanks a lot.
Still remember dealing with LOD, in my caravan. LOL

3com
Laptop: Lenovo - Intel(R) Celeron(R) CPU 1005M @ 1.90GHz

OS: Windows 10 (64) - Ram: 4 gb - Hd: 283 gb - Video card: Intel(R) HD Graphics

PM
rolfy
18
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 3rd Apr 2016 21:33
Actually you didn't read it wrong just needed answering

As for the second question, GG no longer produces .bin files for entities.
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 3rd Apr 2016 22:52
Quote: "Since I was unable to even select sub objects (only faces) it may be that I have missed an import option myself and collapsed the mesh in error just like you did with the smoothing groups
Can you see what each LOD mesh has been named after import to Fragmotion? If so it may give an idea of what went wrong with this particular model."


In Fragmotion I see one mesh and 3 groups which I can select separately. I can also see 4 bones which have the LOD naming
convention. I can not automatically separate the 3 groups into 3 separate meshes. I recently worked with the author of Fragmotion
to help him fix the Fragmotion DirectX exporter so that it would export groups as limbs for use in DBPro. Considering this GG should be able to separate them as limbs it loads them.

I will test if I delete the bones and rename the groups to the LOD convention and export from Fragmotion if it then works with GG
with only one mesh. It appears that when I open the model with Fragmotion it renders the smoothing groups in the viewport but does not list them.
Then on export it does not have the smoothing groups. I can however fix them in Fragmotion before export.
I have attached a screen shot of Fragmotion when the model is first opened.



The coffee is lovely dark and deep,and I have code to write before I sleep.

Attachments

Login to view attachments
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 4th Apr 2016 00:19
I deleted the bones and renamed the groups for LODs but when I try to light map the mapper crashes
with an old DBPro runtime error 7021 which if I remember correctly is an illegal limb number error.
I have attached the model for Lee to test and determine the error in GG. Are there criteria for making models with LODs
to get them to work properly in GG? Do they have to have bones even if they are not animated?
The coffee is lovely dark and deep,and I have code to write before I sleep.

Attachments

Login to view attachments
rolfy
18
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 4th Apr 2016 00:36 Edited at: 4th Apr 2016 00:38
You are unlikely to lightmap an animated object since it would need to be dynamic anyhow and no point in baking shadows onto moving objects so we won't get into that.
LOD naming is very simple

LOD_0
LOD_1
LOD_2

Export as three unattached meshes and all should work fine. These bones are generated in GG and again I reckon are more for editing purposes as we discussed long ago in this thread. If these models are being exported correctly then the issue may be caused by GG adding these bones but since it appears some are fine then I am inclined to go with the model being wrong. All the same it can be hard to tell if any of these working models have LOD levels without opening them to take a look, it might help to narrow it down further.

Pretty sure if you open the .x you wont see these bones, they will be present in the dbo though.
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 4th Apr 2016 01:23
Quote: "You are unlikely to lightmap an animated object since it would need to be dynamic anyhow and no point in baking shadows onto moving objects so we won't get into that. "


I never implied that I would light map an animated object I was asking whether or not an object need bones to work correctly with LOD.
In the original model the bones have the LOD naming convention and the groups of meshes do not.
When I deleted the bones and named the groups with the LOD naming convention it crashes the light mapper.

Quote: "LOD_0
LOD_1
LOD_2"


This is not the naming convention used in the other models.

Quote: "Export as three unattached meshes and all should work fine. These bones are generated in GG and again I reckon are more for editing purposes as we discussed long ago in this thread. If these models are being exported correctly then the issue may be caused by GG adding these bones but since it appears some are fine then I am inclined to go with the model being wrong. All the same it can be hard to tell if any of these working models have LOD levels without opening them to take a look, it might help to narrow it down further."


The bones are not being generated by GG and are in the .x model file when I open with Fragmotion, and I believe you are incorrect that the bones are used for editing purposes do you have any facts to back that up.

Quote: "Pretty sure if you open the .x you wont see these bones, they will be present in the dbo though."


As discussed earlier in this thread they are in the .x file have you actually looked.
Perpetrating in accurate information is not going to determine what the real problem is.
What I am doing is trying to narrow down the problem not just spouting guess as facts to disprove what I am posting.
The coffee is lovely dark and deep,and I have code to write before I sleep.
rolfy
18
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 4th Apr 2016 01:32 Edited at: 4th Apr 2016 02:20
Quote: "As discussed earlier in this thread they are in the .x file have you actually looked.
Perpetrating in accurate information is not going to determine what the real problem is.
What I am doing is trying to narrow down the problem not just spouting guess as facts to disprove what I am posting.."

I don't have to since I have actually created several models with LOD since it was first introduced, it's what I do....modeling for GG ya know?
Didn't use bones didn't apply a skin modifier no added extras whatsoever and never had any issues with any of my models, so if my inaccurate info is making it difficult you will be happy to be left to it

While your at it you might want to try a different software for import your are obviously getting 'inaccurate' info using Fragmotion..

If someone tells me meshes have root bones that were never there before the editor was changed up with widgets then I can only assume GG adds these for use with the widget since they serve absolutely no other purpose (not guessing here since I nor any other modeler put 'em in there) if you find that Fragmotion is adding these on import from .x then you been on the wrong track all along. Good luck with your conclusions if that is the case.
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 4th Apr 2016 03:05
Well it is very obvious that you did not look in the X file or you would have seen the bones listed.
GG does not export .X files so it is very obvious that GG is not adding bones to the .x files.
Has GG magically added bones to any of your models that you made if so provide proof.
I have not seen any proof that any of your models work with the light mapper. Have you tested them?

Fragmotion is not adding anything on import just reading in what is in the X file which can verified opening the
.X file in notepad. I have created my own models with out bones and used them in GG works just fine with the widgets
and GG did not magically add bones to the .X files. The bones can plainly be see in the X files using notepad along with
vertices assigned to them. If GG is that good that it can add bones place them correctly and assign vertices to them and save back out to .x then it should have no problem light mapping a model with LODs.

The store modelers should have been supplied with the correct information on how models should be
to work correctly with GG. As one of the store sellers you should not be perpetrating myths because inexperienced
users might think you actually know what you are talking about.

My goal was to find out if the light mapper is working correctly and if so what are the model specifications if any
to work correctly with it. I have proven that the light mapper works correctly now I just need to clarify the models
speciation's to work correctly with GG.


The coffee is lovely dark and deep,and I have code to write before I sleep.
rolfy
18
Years of Service
User Offline
Joined: 23rd Jun 2006
Location:
Posted: 4th Apr 2016 03:31
It's ok I obviously have no idea what I am talking about and forgot I added bones and skin modifier to every single model I ever made without realising it as did every other Artist who ever made a model for GG, we is all stupid and should be thoroughly chastised. We will wait till the industry standard is defined in stone and stop making these sub par models which worked fine in any other engine till GG raised the bar.
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 4th Apr 2016 16:06
You are stating what you believe is happening with out providing proof that GG is altering your .X files. You are also stating that other artists have had it happen to there models. If other artists believe this is happing to their models please post.
You are stating that GG adds and needs these bones for the widget system. Lee could you confirm this?

I am trying to determine what needs to be corrected to get the best results in GG. If the problem is that some models
are different then the question is can this be accounted for in the light mapper code. If not then what needs to change
in the models and what is the simplest way to make the changes. I appreciated your initial post because it drew my attention
to the now proven fact that the light mapper is having problems with models with LOD meshes. The question for Lee is can this
be handled by GG or do the models need to be changed. I posted above that in testing the supply drop model when I removed the bones (which had the LOD naming convention) and renamed the mesh groups with the LOD names the model crashes the light mapper with the DBPro runtime error 7021.
I believe this error means that a limb number is not valid. Hopefully this can help Lee debug this problem.
The coffee is lovely dark and deep,and I have code to write before I sleep.
3com
10
Years of Service
User Offline
Joined: 18th May 2014
Location: Catalonia
Posted: 4th Apr 2016 16:59
As far as I know LOD is intended to save polys, so at the end, is just the LOD0 model who LM need to care of.
In anothers words, why LM need lightmapping LOD1 and LOD2, when they appears just when player is far away?

If above statement is true, so LOD is not the problem, since LM just take care of the LOD0 one, or at least should do it; just my thought.

GG should not take care of nothing (chars, items, lights, decals, veg, etc) than is not in the player range, in the player view,
this will save fps, memm, cpu, and so on.
In another words, why waste mem calculating one tree position, if it is so far from the player pos.

If you removed the bones, and get 7021 error, "#define RUNTIMEERROR_LIMBNUMBERILLEGAL 7021", While we might say ,that one thing is a consequence of the other.

I'm not an expert, but I think from time to time, and I thing about:

Action: I had removed bones from the model.
Consecuence: I got error 7021
Conclusion: there should be stete in any place, the number of limbs (bones), than now does not match with the real one.
Step: locate tha place (if any) and change bones number, so it match fine, and finito problem.

3com




3com
Laptop: Lenovo - Intel(R) Celeron(R) CPU 1005M @ 1.90GHz

OS: Windows 10 (64) - Ram: 4 gb - Hd: 283 gb - Video card: Intel(R) HD Graphics

PM
synchromesh
Forum Support
10
Years of Service
User Offline
Joined: 24th Jan 2014
Location:
Posted: 4th Apr 2016 18:02 Edited at: 4th Apr 2016 18:03
There is only one person that can answer this accuratly and that is Lee
For the moment i will lock the thread and email Lee with the link to respond before it gets to heated
The only person ever to get all his work done by "Friday" was Robinson Crusoe..
PM
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 4th Apr 2016 19:43 Edited at: 4th Apr 2016 19:45
I never thought lightmapping could be so exciting! I can give you the overview on how the light mapper works, but I have also included the main C++ source code to the core routine which prepares and light maps the scene, which should give the C++ users out there a glimpse into how I go about choosing what to lightmap, and to scare the pants off the non C++ users who can thank their lucky stars someone else is dealing with the code.

Essentially, as seen in the attached image, which was taken from my Asset Importer tool, that you have three floating meshes, each one holds a version of the crate at different polygon counts. You will also notice the smoothing group on the lower polygon variants could do with some improvement if you use the AssImp tool and load the SupplyDropV1.x into it. You then have what I call limbs (coders can call them frames), with a parent limb acting as the root and then three child limbs from this parent, each one referencing one of the meshes. It is the limb name (frame name) which holds the all important text to identify whether the limb is a regular model or whether it's a special LOD model. A special LOD model names each limb to identify which referenced mesh is high polygon, medium polygon or low polygon. A great example of a working LOD model would be the attached AssImp-CombatBuilding.png image which shows the three limbs named as LOD_0, LOD_1 and LOD_2. When the light mapper scans all the models in the scene, it will find the limb name LOD_0 and prefer it over the other two as it will always attempt to find the highest polygon mesh to lightmap (see code below).

I suspect the SupplyDropV1.X model has a few issues, such as not having a limb named LOD_0 which might cause it to use ALL THREE meshes in the lightmap process and produce too many shadows and artefacts. I also suspect the normals are wrong in the mesh too given the improvements demonstrated in the thread above. Alas, I simply don't have the time to thoroughly test every model that comes through, and if they look good, with the right material and collision, they normally go on to the public. If I did this for the thousands of models we've got through so far, I doubt I would have had time to write even a single line of code. I am however happy to get reports on suspicious models and refer those to the original artist so they can make corrections, and it looks like the SupplyDrop model will be getting this treatment. if you find any more, please do pass them onto me and I can get the assets fixed and included in the next build. I am also very happy to receive fixed versions of models and FPE files, as that makes even more sense to me as it can go out all the sooner.

Here is the current light mapper baking code for future reference:



You can email me directly at lee@thegamecreators.com if you have specific models in the default assets (or DLC) you feel should be fixed, and please indicate the exact nature of the issue with the model/entity, thanks. For models on the online asset store, you can contact the authors of those models directly who will be happy to make the corrections for you (just like coders, artists are always looking to improve their skillsets).
PC SPECS: Windows 8.1 Pro 64-bit, Intel Core i7-5930K (PASSMARK:13645), NVIDIA Geforce GTX 980 GPU (PASSMARK:9762) , 32GB RAM

Attachments

Login to view attachments
synchromesh
Forum Support
10
Years of Service
User Offline
Joined: 24th Jan 2014
Location:
Posted: 4th Apr 2016 19:53
Thanks Lee ...
The only person ever to get all his work done by "Friday" was Robinson Crusoe..
PM
Pirate Myke
Forum Support
14
Years of Service
User Offline
Joined: 31st May 2010
Location: El Dorado, California
Posted: 4th Apr 2016 19:58
Thank you Lee. Thread unlocked now.
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2400 Mhz, 4 Core(s), 4 Logical Processor(s), 8gb RAM, Nvidia gtx660, Windows 7 Pro 64bit, Screen resolution 1680 x 1050.

Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 5th Apr 2016 02:54 Edited at: 5th Apr 2016 02:55
Thanks Lee for clarifying how a model needs to be set up for LOD.
I had incorrectly thought that because the model was not an animated model that it did not need
bones and that just the meshes could have the LOD naming convention.
For the modelers out there this is what I have determined you need to do in your modeling program
so the models will work correctly in GG.

If you are creating a model with LODs you need to create a bone for each LOD mesh and assign the vertices of
that mesh to the bone. The bones name must match the naming convention described above in Lee's post.
The model will then work correctly with the light mapper and the LOD system.

My next question about the light mapper concerns static lights. In the attached image the static light
does not create shadows inside the building and seems to be lighting faces that should not be lit.
Should it create shadows from the beams in the barn?
The coffee is lovely dark and deep,and I have code to write before I sleep.

Attachments

Login to view attachments
Wolf
Forum Support
17
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 5th Apr 2016 09:59
@Stab: Try doubling the value of "lightmappingsizeentity", decreasing the ambience and increasing the surface value level.



-Wolf
"When I contradict myself, I am telling the truth"
"absurdity has become necessity"
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 5th Apr 2016 18:12
That did the trick I increased it to 2048. Now I have good looking shadows.
The coffee is lovely dark and deep,and I have code to write before I sleep.
Stab in the Dark software
GameGuru TGC Backer
21
Years of Service
User Offline
Joined: 12th Dec 2002
Location: Upstate New York USA
Posted: 6th Apr 2016 13:46
A final post showing the results of light mapping once the models were fixed.
I am pleased to say I am happy with the results.
The coffee is lovely dark and deep,and I have code to write before I sleep.

Attachments

Login to view attachments
LeeBamber
TGC Lead Developer
24
Years of Service
User Offline
Joined: 21st Jan 2000
Location: England
Posted: 11th Apr 2016 11:10
Could you do me (and the whole GameGuru community) a huge favor and send me the fixed models so I can add them to the next update, I am sure you will get much karma from the universe
PC SPECS: Windows 8.1 Pro 64-bit, Intel Core i7-5930K (PASSMARK:13645), NVIDIA Geforce GTX 980 GPU (PASSMARK:9762) , 32GB RAM

Login to post a reply

Server time is: 2024-11-25 06:28:44
Your offset time is: 2024-11-25 06:28:44