dont use groups on COLs. zm cant handle it and the game will crash. the simplest solution for this is just to attach these objects. Collision works fine in game and even no crashes in R* editor.matt4312 wrote:Thanks for looking into it for me,
Is it just my chassis collision that is making it crash then or don't you know at the moment?
Report Import/Export bugs here
Re: Report Import/Export bugs here
Re: Report Import/Export bugs here
ZM handles it quite well. it feels like FiveM does not understand such groups of collisions properly. At least I can see such a collision being able to re-import into zmod properly and game dealing with such a .yft file quite well.Gta5KoRn wrote:dont use groups on COLs. zm cant handle it and the game will crash....matt4312 wrote:Thanks for looking into it for me,
Is it just my chassis collision that is making it crash then or don't you know at the moment?
Also, it was reported the cause of this bug is a usage of geometry objects inside COLs that have "Deformable" option toggle off. As a background: such an objects are stored as BVH (bound volume hierarchy) and used generally for small pieces of collisions (inside boats, planes and trucks to specify obstacles/ladders "inside" of vehicle).
Re: Report Import/Export bugs here
Ok, just a bit of background on why I used the grouped collisions. I had a problem were I had 1 chassis collision and set it to deformable and it would interact with the world but players could walk though it and bullets would go though it etc. I asked on here and it was suggested to use a grouped col. I have removed the group col on one of the cars after you said this could be a problem to debug it and no success still the same error...
Is there anything else that could be effecting this?
Thanks for the continued help on this btw
Is there anything else that could be effecting this?
Thanks for the continued help on this btw
Re: Report Import/Export bugs here
not really. there was a myth that the train mods are unstable in game. (not fiveM) and where crashing the game and didnt work in R* editor. I think Mrgtamodsgerman wrote you about this problem before. but after loooong experiments and research i found out the the problem was caused from grouped COLs. Attaching them solved the problem. The game is stable and everything works fine in R* editor as well.
Re: Report Import/Export bugs here
FiveM merely performs validation on the polygon edges ('Siblings' in OpenIV, 2nd set of int16s) in phBoundGeometry->polygons.Oleg wrote:ZM handles it quite well. it feels like FiveM does not understand such groups of collisions properly. At least I can see such a collision being able to re-import into zmod properly and game dealing with such a .yft file quite well.
In the case of ZModeler-exported collisions that cause this error (and, often, a crash deeper in game collision solving code, which this crash detection exists to prevent), these shared edges are invalidly paired, as a calculation (seen here, comparable with what rage::PrimitiveTriangle::m8 performs) fails, because these polygon siblings do not actually match the polygon that is situated 'next' to this mesh portion (sharing the specific edge).
phBoundBVH indeed is required so that peds can collide with said collision properly - ped dynamics for whatever reason do not work with phBoundGeometry.Also, it was reported the cause of this bug is a usage of geometry objects inside COLs that have "Deformable" option toggle off. As a background: such an objects are stored as BVH (bound volume hierarchy) and used generally for small pieces of collisions (inside boats, planes and trucks to specify obstacles/ladders "inside" of vehicle).
This should not matter for this FiveM issue, however, as the corrupting fields are in phBoundGeometry, which is a parent class for phBoundBVH.
-
- Posts: 18
- Joined: Sat Sep 10, 2016 11:13 am
Re: Report Import/Export bugs here
On export, fresh convert, into police2 slot and using the ingot default model to convert to. No error messages on export.
Re: Report Import/Export bugs here
Ohh, so the error was related to poly siblings polygons rather than vertices. I was mislead by the text of error message. Thanks for clearing this out for me.hydrogen wrote:FiveM merely performs validation on the polygon edges 'Siblings'...
The fix will be available in next version of zmod. Those who use to test x64 beta can redownload beta package and test it right away.
Re: Report Import/Export bugs here
waiting for the update over 1 month. When can we expect it?
btw: an old bug - https://i.imgur.com/rLi4prO.jpg
the front view window sometimes thinks that it is the Back view window. I have to switch to another view and then switch back to front, to have it.
btw: an old bug - https://i.imgur.com/rLi4prO.jpg
the front view window sometimes thinks that it is the Back view window. I have to switch to another view and then switch back to front, to have it.
Re: Report Import/Export bugs here
the fix will be available in version 3.2.0. I can't release any update to 3.1.5 currently.Gta5KoRn wrote:waiting for the update over 1 month. When can we expect it?
btw: an old bug - https://i.imgur.com/rLi4prO.jpg
the front view window sometimes thinks that it is the Back view window. I have to switch to another view and then switch back to front, to have it.
Concerning the viewport issue: front/back bug confirmed. seems to happen after pressing "Fit" button.
Edit: viewport/fit bugfix will be available in 3.2.0 too
Re: Report Import/Export bugs here
alright. do you have a release date for 3.2.0?
-
- Posts: 1
- Joined: Wed Nov 29, 2017 12:05 pm
Re: Report Import/Export bugs here
Model is just locked by author, u can't modify it.BorgoMadonno wrote:Hello, I just bought a 30day license, already linked to my pc. The problem is when I try to import yft files I click Import but nothing happens. Nothing loads in ZModeler.
I already activated the license, I have 31 days left. So what am I missing?
Thanks.
Re: Report Import/Export bugs here
Locked model should show dimmed/disabled "Import" button. However, it is quite possible the model is locked. Can you try to import any original game model to check whether everything is set up properly or not?
Re: Report Import/Export bugs here
Some V shaders use what 3DS calls "Vertex Illumination" channel for some properties, how is this handled in zmod?
Also I remember one thing that used to be bugged in past: when working on a fragment, if the root dummy is not centered in 0,0,0 the skeleton is bugged on export. It looks like the bones' positions use a world coords system instead of the one relative to the root dummy. This causes wrong animations on animated parts (doors,wheels and so on)(models are at the correct position but they animate around a bone which has an offset made of actual zmod position+relative offset of the root dummy). This was fixed after importing the .yft back in zmod(which translates the whole model+skeleton) and exporting it again.
Having a root dummy not in 0,0,0 is a common thing since it's also used as center of mass for the chassis.
Also I remember one thing that used to be bugged in past: when working on a fragment, if the root dummy is not centered in 0,0,0 the skeleton is bugged on export. It looks like the bones' positions use a world coords system instead of the one relative to the root dummy. This causes wrong animations on animated parts (doors,wheels and so on)(models are at the correct position but they animate around a bone which has an offset made of actual zmod position+relative offset of the root dummy). This was fixed after importing the .yft back in zmod(which translates the whole model+skeleton) and exporting it again.
Having a root dummy not in 0,0,0 is a common thing since it's also used as center of mass for the chassis.
Re: Report Import/Export bugs here
In most of cases vertex R channel is ambient occlusion prelit shading, concerning illumination, you are probably referring to "emissive" set of shaders - they use vertex Alpha as a strength of emissive light. I could be wrong, there was a topic on this issue earlier.
Re: Report Import/Export bugs here
it's used for example on terrain_cb_w_4lyr_2tex_blend_pxm_spm shader to set the opacity of layers. In this case green and blue levels are used to set the opacity.
Re: Report Import/Export bugs here
this shader uses green and blue per-vertex channel for textures transition.
Edit: this particular shader you specify uses additional lookup texture (MASKMAP, UV#2) for blending 4 layers. it does not seem to be affected by per-vertex color even thought it does use per-vertex green and blue for some purpose.
Edit: this particular shader you specify uses additional lookup texture (MASKMAP, UV#2) for blending 4 layers. it does not seem to be affected by per-vertex color even thought it does use per-vertex green and blue for some purpose.
Re: Report Import/Export bugs here
Zm is sometimes crashing when switching from UV Mapper to another view
Re: Report Import/Export bugs here
if you get a .z3d file that can reproduce this problem, send it to me please.
Re: Report Import/Export bugs here
Dear Oleg,
I've recently encountered an error with exporting wheels from ZM3. I export separate 'tuning wheels' (as .ydr-files) in order to have multiple wheel styles for my cars, as seen in the images below. This worked perfectly, until this week when I tried to do so again. I have to say I am completely stumped; I have changed nothing in the .zm3 file, the only thing I have done is export it again. I will admit, it's been a while since I did this, so I am not entirely sure about my export settings either.
Anyway, the old export (from 17-06-17) behaves correctly:
This is the new export, which obviously isn't right:
I am using these export settings:
When I import the wheels back into ZM3 they look completely identical to me. Do you have any idea what might be causing this? Would be great if you could help me out!
If necessary I can send you the source ZM3-file and the 2 exports.
Regards,
Vertelvis
I've recently encountered an error with exporting wheels from ZM3. I export separate 'tuning wheels' (as .ydr-files) in order to have multiple wheel styles for my cars, as seen in the images below. This worked perfectly, until this week when I tried to do so again. I have to say I am completely stumped; I have changed nothing in the .zm3 file, the only thing I have done is export it again. I will admit, it's been a while since I did this, so I am not entirely sure about my export settings either.
Anyway, the old export (from 17-06-17) behaves correctly:
This is the new export, which obviously isn't right:
I am using these export settings:
When I import the wheels back into ZM3 they look completely identical to me. Do you have any idea what might be causing this? Would be great if you could help me out!
If necessary I can send you the source ZM3-file and the 2 exports.
Regards,
Vertelvis
Re: Report Import/Export bugs here
does toggling skeletal fixes the problem?
Re: Report Import/Export bugs here
Sadly not, this is what happens when I check skeletal on export:
Re: Report Import/Export bugs here
i dont know how you can reproduce the problem... it can work fine and then randomly crash while working in UV editor or changing the view from it. I have the video of few crashes, should i upload it?Oleg wrote:if you get a .z3d file that can reproduce this problem, send it to me please.
Re: Report Import/Export bugs here
no, the video will give no information to fix the problem. when you close uv-mapper, zmodeler clears uv-mapping objects. I need a .z3d file to locate a problematic area.
concerning wheel, it looks like their axes are wrong in .ydr file compared to .yft file. have you tried to import/export original tuning wheels to see whether they will have the same problem after just being import/exported?
concerning wheel, it looks like their axes are wrong in .ydr file compared to .yft file. have you tried to import/export original tuning wheels to see whether they will have the same problem after just being import/exported?
Re: Report Import/Export bugs here
Hi Oleg,
I managed to fix the problem, but the fix still confuses me. It turns out that the location of the root dummy node for the wheel has to be at 0,0,0. The reason that it was not there is because I model the wheels and the car in the same scene, the same Z3D-file, in order to coordinate between them, as seen below:
Now it turns out that when I set the position of the root dummy node for the wheel to 0,0,0 as below, and export it....
It turns out fine!
This is using these export settings:
The strange thing is that while this works, I'm absolutely sure this wasn't necessary before and it also worked fine while leaving the root dummy in the position that makes sense in relation to the car. Do you have any idea what could have caused this change? Now I have a fix it's no biggie, but I still find it puzzling.
Thanks for your help!
Vertelvis
I managed to fix the problem, but the fix still confuses me. It turns out that the location of the root dummy node for the wheel has to be at 0,0,0. The reason that it was not there is because I model the wheels and the car in the same scene, the same Z3D-file, in order to coordinate between them, as seen below:
Now it turns out that when I set the position of the root dummy node for the wheel to 0,0,0 as below, and export it....
It turns out fine!
This is using these export settings:
The strange thing is that while this works, I'm absolutely sure this wasn't necessary before and it also worked fine while leaving the root dummy in the position that makes sense in relation to the car. Do you have any idea what could have caused this change? Now I have a fix it's no biggie, but I still find it puzzling.
Thanks for your help!
Vertelvis