I've had just a flat colour on the model earlier and the seams were still present - I should probably pad the UVs out a little more though regardless
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages1
#2
WWMT Questions / Re: Seam Lines (Projected Textures)
February 17, 2016, 07:10:38 AM
Whoops, I'd converted it to editable mesh as an attempt to sort the issue; was previously using editable poly. I don't know where those bizzare little spikes around the edges of the dimples came from, so I've recreated the prop... aaaaand... they're still there. The normals aren't messed up as far as I can tell. It might be a problem with the engine side, so I'll just have to put up with it. Thanks for the help though!
#3
WWMT Questions / Re: Seam Lines (Projected Textures)
February 16, 2016, 01:44:00 PM
Sent it along using the contact form, thanks!
#4
WWMT Questions / Re: Seam Lines (Projected Textures)
February 16, 2016, 04:01:01 AM
Gave re-exporting with explicit normals on WW Pro a go, and no change. It's not a texture issue as it doesn't occur when a projected texture isn't laid upon it (and they're used pretty heavily for flashlights and dynamic environment lighting and such). No flashlight: http://puu.sh/n9Rf4/c0ef11d7a7.jpg
#5
WWMT Questions / Seam Lines (Projected Textures)
February 15, 2016, 05:28:31 PM
Hi there! Using WallWorm Pro for my Portal 2 engine game, and I'm having a weird issue wherein seams of polygons are drawn in projected texture flashlight shadows on objects exported from 3DS Max (does not occur on Valve's original models). Smoothing groups and materials are set up, and there are no gaps between these polys in 3DS. (Screenshots demonstrating this issue are below)
http://puu.sh/n9kmF/720b70f795.jpg
http://puu.sh/n9knM/b4b5706673.jpg
http://puu.sh/n9knx/beaa0c11da.jpg
http://puu.sh/n9kmm/8661f34816.jpg
Any idea how to fix this issue?
http://puu.sh/n9kmF/720b70f795.jpg
http://puu.sh/n9knM/b4b5706673.jpg
http://puu.sh/n9knx/beaa0c11da.jpg
http://puu.sh/n9kmm/8661f34816.jpg
Any idea how to fix this issue?
#6
WWMT Questions / Re: Static Concave Collisions And Moving Parts
June 02, 2015, 08:16:03 AM
Managed to suss it out - Not skinned the arch to any bones, but zeroed the position, then moved the vertexes themselves to the right place, along with "$upaxis Z" at the top of the QC to sort the rotation problem. There's probably a better way to do this, it was stupidly awkward, but I got there in the end.
Thanks anyway, keep up the good work with WWMT! :D
Thanks anyway, keep up the good work with WWMT! :D
#7
WWMT Questions / Static Concave Collisions And Moving Parts
June 01, 2015, 08:46:39 PM
Hi! I've been trying to do a modified form of the doors from Portal 2, and I've hit a snag with the collisions.
The stock P2 doors have a static (or at least, attached to the base bone) archway, as well as two moving pieces that act as the sliding door. (pictured: http://puu.sh/i94zK/e949c1315b.jpg)
Recompiling with the decompiled collision model Crowbar outputs creates a single collision mesh (which I have come to expect from decompilation tools), and so I remade the collision model. Did all the usual stuff - no concave pieces, each piece with it's own smoothing group, so on - but now while the door parts are just fine, the arch is still one large convex block (that is often rotated to the side... not quite sure why that is, likely mis-parented or something, pictured: http://puu.sh/i94SC/ec34ec8703.jpg)
So, don't suppose you guys can see what's wrong here? I'm used to working with static models, so there's probably something I'm doing very wrong.
Thanks!
EDIT: If I don't assign a bone to the arch pieces, all the parts just kinda jump to the middle (like so: http://puu.sh/i96Ju/584489db29.jpg, should be like this: http://puu.sh/i96Nc/8163ec6632.jpg)
The stock P2 doors have a static (or at least, attached to the base bone) archway, as well as two moving pieces that act as the sliding door. (pictured: http://puu.sh/i94zK/e949c1315b.jpg)
Recompiling with the decompiled collision model Crowbar outputs creates a single collision mesh (which I have come to expect from decompilation tools), and so I remade the collision model. Did all the usual stuff - no concave pieces, each piece with it's own smoothing group, so on - but now while the door parts are just fine, the arch is still one large convex block (that is often rotated to the side... not quite sure why that is, likely mis-parented or something, pictured: http://puu.sh/i94SC/ec34ec8703.jpg)
So, don't suppose you guys can see what's wrong here? I'm used to working with static models, so there's probably something I'm doing very wrong.
Thanks!
EDIT: If I don't assign a bone to the arch pieces, all the parts just kinda jump to the middle (like so: http://puu.sh/i96Ju/584489db29.jpg, should be like this: http://puu.sh/i96Nc/8163ec6632.jpg)
#8
WWMT Questions / Re: Some Help With A Tweak
July 31, 2013, 06:45:55 AM
I've been tinkering for the last few days and I'm pretty sure that its the decompile that has the problem... I don't remember how to make this kind of model though, and all this is doing is confusing me now >.<
#9
WWMT Questions / Some Help With A Tweak
July 28, 2013, 06:11:24 PM
I made a Portal playermodel a while back and today noticed that the bottoms of the feet are SLIGHTLY too long. I no longer have the MAX or SMD/QC files for the model, only the finished MDL file. I decompile it, attempt to fix the issue (by slightly moving the polygons of the soles of the feet to line up with the footsprings). The problem comes along when I recompile...
Yeeeeeeah. Every animation that isn't 'ref' looks like that.
I'm not sure which stage is going wrong, be it the decompile, the import, the edit or the export. Mind lending a hand? I've included male_anims.mdl which needs to be included with the model, but hopefully that'll be in the decompile QC.
All that needs to be done is a teeny tiny height change in the soles of the feet so that it doesn't stick out through the wall on the other side of the Portal, but I can't do this without seriously screwing up the entire model. I've been (attempting) to use the most recent WallWorm tools and 3DS Max 2014 (education edition, if that changes anything).
Thanks!
Model files: http://elitetreacle.info/chellmdl.zip
Yeeeeeeah. Every animation that isn't 'ref' looks like that.
I'm not sure which stage is going wrong, be it the decompile, the import, the edit or the export. Mind lending a hand? I've included male_anims.mdl which needs to be included with the model, but hopefully that'll be in the decompile QC.
All that needs to be done is a teeny tiny height change in the soles of the feet so that it doesn't stick out through the wall on the other side of the Portal, but I can't do this without seriously screwing up the entire model. I've been (attempting) to use the most recent WallWorm tools and 3DS Max 2014 (education edition, if that changes anything).
Thanks!
Model files: http://elitetreacle.info/chellmdl.zip
Pages1
SMF spam blocked by CleanTalk