[KARMA]

i have a strange thing here, with a "new" technique to uvmap a model that i "invented" and tested with the xw i'm mapping
i'll explain the problem with an example:
i have done this 128*128 texture:



as you can see there is more than one element in the same texture but i haven't unwrapped the model, i will do it manually
i will map with a portion of this texture the engines fan, that i have highlighted in this image:
 


for those who don't use truespace, the menu on the right of the material editor (first image) lets you edit the u/v repetitions and the u/v ofsset. With these parameters you can select specific parts of a texture, and you will see on the left icon, that is  the "map preview", the portion of the texture you are going to map with:



since i regullary subdivided the texture it was easy to select the correct portion, now i have only to aplly the map:



pretty simple and very very useful, isn't it?........NOT EXACTLY!!
i converted the model (with cob2fs2) and here is the result:



as you can see the conversion changed the offset of the map
...i thought...maybe its the cob2fs2, i said, i should try with PCS....
result: "fatal error: stack overflow protection was engaged, conversion aborted after GenerateBSP reached depth of 1000 recursion" (btw..what does it means?)

the strange point is that not all the maps are distorted after conversion..after some checks i noticed that ALL the vertical offsets are distorted, while ALL the horizontal offsets are correct, like if cob2fs2 isn't able to convert this kind of data....and i can't check if pcs did it instead, since it doesn't work for this model.....
damn!!!!
i still can make it, i can work on the uvmaps sizes and coordinations manually instead of working over the mapping parameters...it isnt difficult but it would be very very....annoying
anyone has some suggestions? consider that this way to "unwrap" a model may be, in my opinion, very very useful, under certain conditions

[WMCoolmon]

I'm sorry, but...

[KARMA]

[LtNarol]

now that is funny...you can explain this though: R2D2 got sucked into the engine...

[WMCoolmon]

What about different versions of PCS? (If you can find them)
What version did you try?

[ShadowWolf_IH]

actually this may be the X-Wing D variant, R2 units are purposely housed there to keep them from getting shot like R2D2 did.

[Nico]

I'd say cob2pof resets the tiling, to me the map seems to be aligned the right amount horizontally. That's... odd.
Try this: with TS, convert your cob or scn file to 3ds, then save it back to whatever you want, then convert. Stupid, but it might work.

[KARMA]

mmmm i think that i should have choosen a different example:rolleyes:

the version of pcs is the first with support for smooth shading (so not the last one with model preview but if i'm not wrong the one immediatly before)

[karajorma]

If the model has no turrets, lods or debris PCS will give you that message (at least it does with me).

 Put a LOD on it (You might as well make it the lowest poly LOD so you can do it quickly) and try it again.

[Vasudan Admiral]

i've had this prob also and i don't think it looks like that in-game. i made a slave 1 model and made a map for the engines. it only looked correct in truespace and in-game. ie, i had to flip the texture in truespace to get it up the right way, and in modview and fred, it fliped the texture back again. try doing a mission with it in and see if R2 is still hiding in there.

[KARMA]

Originally posted by Vasudan Admiral
i've had this prob also and i don't think it looks like that in-game. i made a slave 1 model and made a map for the engines. it only looked correct in truespace and in-game. ie, i had to flip the texture in truespace to get it up the right way, and in modview and fred, it fliped the texture back again. try doing a mission with it in and see if R2 is still hiding in there.

i'll surely check in game, but what you are talking about seems little diferent and seems related to flipped normals
(ps: you did a slave1??really?how is it?i may be interested!:))

various points:
1: converting to other formats and converting it back doesn't seems to have effect
2:adding lods doesn't make pcs convert it
3:if i detriangulate the model pcs convert it
4: pcs doesn't distort the maps
5:the problem seems related to a bug of cob2fs2 (since pcs works fine with the texture align)
6:if i detriangulate the model some faces have as usual clipping errors and surely i have no intention of spending days manually fixing the clippings with the risk to have a job that pcs will again refuse to convert
is there any way to have pcs converting the model anyway?

[aldo_14]

Originally posted by KARMA

for those who don't use truespace, the menu on the right of the material editor (first image) lets you edit the u/v repetitions and the u/v ofsset. With these parameters you can select specific parts of a texture, and you will see on the left icon, that is  the "map preview", the portion of the texture you are going to map with:



since i regullary subdivided the texture it was easy to select the correct portion, now i have only to aplly the map:
 
 

IIRc, reps <1 cause problems.  You'll have to work with the plane size, methinks.....

when i still worked with Ts to map stuff, i did notcie that the UV reps always seem to get very slightly offset in conversion.... it seems to be a TS thing - 3d exploration shown the same differences as did the FS models.

[Sesquipedalian]

Perhaps this is too easy, but why not just slice the texture in half and apply the engine one on the engines and the R2D2 one onto R2D2?  If the images are on two different texture files, a reset of the texture info ought no to cause any troubles.

[KARMA]

aldo, the point is that only the horizontal offset is changed during conversion, and only if i convert with cob2fs2, with pcs seems ok....unfourtunately pcs can't convert the triangulized model (and the non-triangulized has clipping probs), it gives the damned generateBSP error...
i'll try to upload the model to see if it happens only to me, but in case i'll have to work with the uv plane sizes instead, or elseway i'll try to fix the mesh in order to avoid the pcs error
thats bad cause in this way i was able to unwrap a model without lithunwrap or similia and so to avoid any convertion between 3dformats:(
oh, and sesqui, of course i can do that but it would mean to have about 20 maps intead of the 5 256x256 and the 3 128x128 maps i used...

[Vasudan Admiral]

i did make a slave 1, and i really need to re-do it. it was more a practice than anything, but it looks plausable. the problems begin with it has a huge amount of polys and a lot of them intersect. otherwise it works. pm me if you want pics or anything btw, i built a very, very buggy ssd model a long time ago. ie, i didn't know anything bout modding, so i used segletouch to turret it. with 128 poly turrets bleh. mabey i'll re-do that sometime too.... just if you're intrested

and have you tried the xw in-game yet? cos it has happened to a few other models and they looked fine in-game. and it's not just flipped textures. like this it moved them.

edit: double checked, and i was trying something vagely similar to you. an engine texture was moved up slightly. i think it will look fine in-game. can't test yet, my fs is currently broken and i will need to re-install some time. :doh:

[Bobboau]

3 tips
1) learn how to do real UV mapping
2) use PCS
3) make it out of one subobject !!!

[KARMA]

ehm... sorry bobbau but this is the kind of reply that...well i hate:)

1-i'm still making my own experience in the modding world (ehy i opened for the first time a 3d modelling prog in october-november...) ... as far as i know there is only one way to make experience....to experiment new stuff...... and in my particular case i was trying ways to uvmap that doesn't require external programs (unwrappers) to avoid conversion problems and this way may be a)fast b)very easy

2-pcs does NOT work with this model...i'd like to use it since it wasn't giving this "offset bug" of cob2fs2 but since it gives me a generatebsp error...........................

3- the model (that isn't mine) is already of one subobject........................

[KARMA]

mm i noticed that cob2fs2 doesn't exactly resets the vertical offsets, but just "modify" them, so i thought  that maybe it was possible to "compensate" the modification while texturing, and after some trial and errors i was able to identify the "rule":
it seems that cob2fs2 changes the voffset parameter of textures with this new parameter: voffset+vrepetition
knowing this it was easy to add to the voffsets the relative vrepetition, and obtain that:


unfourtunately it seems that there are also some little model problems, althought there are no holes or clipping  some parts are not "solid" in collision, i have to test if this happens also shooting, but  well, it works:)