EQEmulator Forums

EQEmulator Forums (https://www.eqemulator.org/forums/index.php)
-   Development::Tools (https://www.eqemulator.org/forums/forumdisplay.php?f=593)
-   -   EQG Zone Importer (https://www.eqemulator.org/forums/showthread.php?t=38384)

Packet 06-17-2014 04:54 PM

Quote:

Originally Posted by knowom (Post 231350)
From the looks of it your texture images are opaque rather than transparent as your intending them to be.

My textures are not opaque. Also, I've tried using an opaque alpha mask and that doesn't work for me either.

Zaela_S 06-17-2014 10:06 PM

Quote:

Originally Posted by Packet (Post 231349)
Edit:Actually, I just confirmed that alpha masking doesn't seem to carry over when I export to obj. I re-imported my OBJ back into 3ds max and the textures were fubarred like they are in the screenshot below.

Yeah you're right, I tried in game myself and it doesn't seem to respect alpha. I have no idea again. Nothing jumps out at me. The shader does seem like a logical place to look, though.

Quote:

Originally Posted by Packet (Post 231349)
The materials that are imported (like my trees) are seemingly duplicated.

Whoops, laziness. I just put up a quick fix.

Scorpious2k 06-17-2014 10:25 PM

Didn't Windcatcher have a program that converted a bmp to an image with transparency by adding the alpha layer? I think it came with OpenZone. Maybe it has some clues.

Zaela_S 06-17-2014 10:46 PM

S3D-based zones have a bit flag for texture visibility settings. No direct equivalent in EQG-based zones.

Quote:

Originally Posted by Zaela_S (Post 231368)
The shader does seem like a logical place to look, though.

"Alpha_MPLBasicA.fx" seems like a good place to start. Will test later.

Need to compile a list of shader names at some point, seems like there are a bunch used by zones.

KLS 06-17-2014 11:14 PM

Code:

Mat: brnch Alpha_MPLBumpAT.fx
prop: e_TextureDiffuse0 Di_Birch_branch03.dds
prop: e_TextureNormal0 Di_Birch_branch01_n.dds
prop: e_TextureCoverage0 oakcover.dds
prop: e_TextureFallback0 Di_Birch_branch03.dds
prop: e_fCoverageScale0 0.050000

There's the tree branches on the birch trees from Nektulos.

Packet 06-18-2014 12:17 AM

Quote:

Originally Posted by Scorpious2k (Post 231369)
Didn't Windcatcher have a program that converted a bmp to an image with transparency by adding the alpha layer? I think it came with OpenZone. Maybe it has some clues.

It was built-in to OpenZone, definitely. We could use a material which had two textures. One as the diffuse and the other as the opacity map (the black and white cuttout).

Quote:

Originally Posted by Zaela_S (Post 231368)
Yeah you're right, I tried in game myself and it doesn't seem to respect alpha. I have no idea again. Nothing jumps out at me. The shader does seem like a logical place to look, though.

Whoops, laziness. I just put up a quick fix.

Yeah. I was surprised PNG's worked though so that's good. I think I'm going to install a dds plugin for photoshop cs6 so that I can work with the native texture format now that you've confirmed that I'm not insane.


Quote:

Originally Posted by KLS (Post 231372)
Code:

Mat: brnch Alpha_MPLBumpAT.fx
prop: e_TextureDiffuse0 Di_Birch_branch03.dds
prop: e_TextureNormal0 Di_Birch_branch01_n.dds
prop: e_TextureCoverage0 oakcover.dds
prop: e_TextureFallback0 Di_Birch_branch03.dds
prop: e_fCoverageScale0 0.050000

There's the tree branches on the birch trees from Nektulos.

Interesting. I'll try this again tomorrow and see if I can get this to come out. I suppose the first step is taking out all of these textures and examine which one is which and does what. The normal is obviously the bump mapping and the diffuse is the actual texture itself. So the only thing left is the Fallback & Coverage. I've seen coverage on materials without any alpha masking so I assume it's the fallback but I suppose we'll see tomorrow. Thanks for pointing this out KLS.

Zaela_S 06-18-2014 12:31 AM

Quote:

Originally Posted by Packet (Post 231373)
Yeah. I was surprised PNG's worked though so that's good. I think I'm going to install a dds plugin for photoshop cs6 so that I can work with the native texture format now that you've confirmed that I'm not insane.

DDS isn't any different. It's all the same by the time it gets to the renderer anyway.

Zaela_S 06-18-2014 01:28 AM

Finally got the chance to test. Definitely controlled by the material shader:

Opaque_MaxCB1.fx (tool default)
http://i.imgur.com/4Dt4Tts.png

Alpha_MPLBasicA.fx
http://i.imgur.com/WuSzFet.png

Maybe not that exact one since it seems to have made the alpha texture further away show in front of the closer one around the middle there. But, you know.

Akkadius 06-18-2014 01:55 AM

This is all crazy shit

KLS 06-18-2014 02:04 AM

Looking at the disassembly for EQGraphicsDX9 it appears keywords in shader names determine the basic render method for the material.

There being a major keyword and a minor keyword that determines what render effect it has.

eg:

Code:

WaterFall

Water

Terrain

Lava2

Lava

AddAlpha
        CBSGE1
        CBGG1
        CBSG1
        CBS1
        CB1
        CE1
        CG1
Alpha
        MPLBasic
        MPLBlendNoBump
        MPLBlend
        MPLFull2UV
        MPLFull
        MPLBump2UV
        MPLBump
        MPLSB2UV
        MPLSB
        MPLGB2UV
        MPLGB
        MPLRB2UV
        MPLRB
        C1DTP
        CBSG1_2UV
        CBST2_2UV
        CB1_2UV
        C1_2UV
        CBGGE1
        CBSGE1
        CBSE1
        CBE1
        CBGG1
        CBSG1
        VSB
        CBS1 (applies only if VSB not found)
        CBS_2UV
        CB1
        CE1
        CG1
Chroma
        MPLBasic
        CBSGE1
        CBGG1
        CBSG1
        VSB
        CBS1 (applies only if VSB not found)
        CB1
        CE1
        CG1
AnythingElse (eg Opaque)
        MPLBasic
        MPLBump
        CBSGE1
        CBGG1
        CBSG1
        CBS1
        CB1
        CE1


KLS 06-18-2014 02:26 AM

Code:

Mat: ddbrnch Chroma_MPLBumpAT.fx
prop: e_TextureDiffuse0 Di_Birch_branch_bare.dds
prop: e_TextureNormal0 Di_Birch_branch_bare_n.dds
prop: e_TextureCoverage0 oakcover.dds
prop: e_TextureFallback0 Di_Birch_branch_bare.dds
prop: e_fCoverageScale0 1.000000

Here's another branch, it appears Chroma materials also have some sort of blending to them.

Also are those ropes part of the TER or are they a placeable?

knowom 06-18-2014 02:58 AM

Quote:

Originally Posted by Scorpious2k (Post 231369)
Didn't Windcatcher have a program that converted a bmp to an image with transparency by adding the alpha layer? I think it came with OpenZone. Maybe it has some clues.

Wasn't done by Windcatcher to my knowledge, but is this what you were thinking of? Has to do with magic pink and alpha transparency.
http://www.project1999.com/forums/sh...ad.php?t=32380

Quote:

Originally Posted by Akkadius (Post 231377)
This is all crazy shit

I think we can fairly unanimously agree to that statement. This is rather technical stuff I believe to most of us with no backgrounds in this kind of shit. Even if you had one in this stuff it seems like EQ has it's own way of doing stuff especially early EQ where the common used API's were different Glide vs Direct X.

It's actually quite remarkable and a accomplishment that a game that was dominantly played based on Glide in infancy early days evolved into what it is today and testament to the staying power of the game itself.

Zaela_S 06-18-2014 03:34 AM

Quote:

Originally Posted by KLS (Post 231379)
Also are those ropes part of the TER or are they a placeable?

Was part of the main geometry S3D so I translated it into the TER.

KLS 06-18-2014 05:23 AM

It probably doesn't sort transparent materials within the ter, or perhaps it does it by model and the ter is a huge model with multiple materials that may be transparent.

Packet 06-18-2014 10:12 AM

I think KLS might be onto something. I'm currently playing with the shaders to see what combinations do what and im documenting as I go.

I did have a question regarding shaders that perhaps you two could answer. How does the relation between materials and material properties work? Can there be multiple shaders per each property in a material?

Zaela_S 06-18-2014 10:37 AM

Quote:

Originally Posted by Packet (Post 231391)
Can there be multiple shaders per each property in a material?

Opposite direction, just one shader name per material. Just hard to indicate that in the tool without making the layout weird.

Packet 06-18-2014 11:04 AM

Yeah. I assumed that was the case but I thought I should ask since multiple textures can exist within a material. If I could somehow add AddAlpha to normals or something but oh well.

What're you guys using to explore eqg's since s3dspy only supports s3ds.

Edit: Nvm, I see EQG's in there now. You know, I'm looking around at the physical textures of models in zones. For instance, "Harbingers.eqg". Take a look at "av_skull06_n.dds" and "av_skull06_c.dds" or even the branches KLS was talking about. The _n.dds normal maps all contain the same color as the backdrop that we want to subtract/filter out. Perhaps this is the key in combination with the appropriate shader.

I also noticed "all_alpha.dds" in nektulosa.eqg. Maybe the shader assigned to materials that use this texture will provide some insight as well.

Zaela_S 06-18-2014 11:32 AM

Quote:

Originally Posted by Packet (Post 231393)
What're you guys using to explore eqg's since s3dspy only supports s3ds.

I made a quick replacement as well since S3DSpy seems to crash or hang on certain files for no reason.

Packet 06-18-2014 02:23 PM

Awesome. Thank you. I'm still trying to figure out this alpha masking. I tried using normals with the chroma shader like the references I've seen have it set but that did nothing so next up is to cycle through the alpha shaders.

KLS 06-18-2014 04:38 PM

EQEmu has a command line pfs archive tool as well:

https://github.com/EQEmu/zone-utilities/releases

Packet 06-18-2014 08:03 PM

Quote:

Originally Posted by Zaela_S (Post 231376)
Finally got the chance to test. Definitely controlled by the material shader:

Opaque_MaxCB1.fx (tool default)
http://i.imgur.com/4Dt4Tts.png

Alpha_MPLBasicA.fx
http://i.imgur.com/WuSzFet.png

Maybe not that exact one since it seems to have made the alpha texture further away show in front of the closer one around the middle there. But, you know.

Quick question. How did you do that?

Zaela_S 06-18-2014 10:51 PM

Quote:

Originally Posted by Packet (Post 231404)
Quick question. How did you do that?

Hmm? Find material, type in shader name, save? Or did you mean something else? The original texture already had the transparent parts set to 0 alpha.

Packet 06-19-2014 11:37 AM

Quote:

Originally Posted by Zaela_S (Post 231411)
Hmm? Find material, type in shader name, save? Or did you mean something else? The original texture already had the transparent parts set to 0 alpha.

Ok. So after about 60 accumulative hours of trying to figure out why my transparent materials were not coming in, I finally figured it out. I got the alpha masking in and it looks like I was completely wrong about texture transparency support (as you mentioned above). I imported .png's (4096x4096) with transparency while using the Alpha_VBS.fx shader on the material and it worked however, now my objects can be seen through other objects that share the same material. So I figured it was because my materials were being used on objects that need to be opaque so what I've done is separate the foliage leaves from the tree trunk(s) and created the same material using the default opaque shader. Now the tree leaves are masked and the trees/rocks/etc are no longer obscured (kinda).

With that being said, I've decided to attempt to separate the geometry which is being imported as .ter. Instead, I'd like to import the .mod files now. My terrain model is separate from all of the trees and rocks, etc... I imported the terrain without a hitch. I then navigated to the "Models" tab and right-click->imported the terrain objects obj file.

It seemed to process them all just fine and now I have a terrain_objects.mod in the model list. I then right-clicked the next box and hit "add placement", selected the terrain_objects and left the x y z and scale alone since it should match the terrain (as I didn't move anything from its original location). Now my client crashes. Without the .mod, it works fine.

Here's the eq client error log:
Quote:

2014-06-19 10:51:45 fatal error in main thread Code = c0000005 ADDR=0x02c43713
2014-06-19 10:51:45
2014-06-19 10:51:45 EAX=00000001 EBX=18a96a36 ECX=00000000 EDX=0018d00c
2014-06-19 10:51:46
2014-06-19 10:51:46 ESI=00000000 EDI=18a96a02 EBP=18a96a4e ESP=0018cf9c
2014-06-19 10:51:46
2014-06-19 10:51:46 Process was trying to READ invalid data.
2014-06-19 10:51:46
2014-06-19 10:51:46 Invalid access occurred at virtual address 0x00000000.
2014-06-19 10:51:46
2014-06-19 10:51:46 Fatal error occurred in mainthread! (Release Client #630)
2014-06-19 10:51:46
2014-06-19 10:51:46 Client Version: Oct 31 2005 10:33:37
2014-06-19 10:51:46 Skin Directory: UIFiles\Default\
2014-06-19 10:51:46
2014-06-19 10:51:46 Graphics DLL Loaded: Graphics DLL Version 2.00.0258
2014-06-19 10:51:46 Graphics Build Date: Oct 25 2005 17:11:03
2014-06-19 10:51:46 Video Card: NVIDIA GeForce GTX 570 , 9.18.13.1106
2014-06-19 10:51:46
2014-06-19 10:51:46 Crash (char = Packet, zone = nexus)
2014-06-19 10:51:46
2014-06-19 10:51:46 Local Player's World location at time of crash: -62.000000, 55.625000, -99.250000.
2014-06-19 10:51:47
2014-06-19 10:51:47 Gamestate at crash = 253
2014-06-19 10:51:47
2014-06-19 10:51:47 Processor: 8 of type 586
2014-06-19 10:51:47 Physical memory: 0 Megs
2014-06-19 10:51:47 CPU: Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz 3395837
This is just a note that importing as .mod didn't work for me. Importing it all as terrain did though however, there is another issue regarding UV mapping. When I imported the objs, the UV mapping is off by an inch. It's not precise however if I view my .obj's in a model viewer, the UV mapping is spot on. I can deal with uv mapping not being as precise but I'd prefer it not to be. I did also notice that after importing an obj as terrain, all of the textures were flipped upside down. This didn't effect how they looked (other than the shifting by an inch) however, it's likely the culprit. Any ideas?

Edit: It looks like OBJ exporting via 3ds Max produces obscured UV's. I'm going to try Maya or Blender instead, I'll post results.

http://xonos.net/zone/ss12.png

Packet 06-19-2014 01:43 PM

Normal maps (bump mapping) working well. Hurray! :) I added way too much depth to my normal maps for testing.

http://xonos.net/zone/ss13.png

Zaela_S 06-19-2014 01:44 PM

Quote:

Originally Posted by Packet (Post 231417)
It seemed to process them all just fine and now I have a terrain_objects.mod in the model list. I then right-clicked the next box and hit "add placement", selected the terrain_objects and left the x y z and scale alone since it should match the terrain (as I didn't move anything from its original location). Now my client crashes. Without the .mod, it works fine.

Found bug for MOD import, should be fixed. Last place I thought to look, didn't occur to me until I had just left the house of course ;p

That stuff looks pretty nice!

Packet 06-19-2014 02:21 PM

Awesome. I'll let you know how it works out. Great job Zaela.

On the triangle editing which allows you to set specific flags on a specific vertex - I have a long list which contains 172852 vertices. It's great to see what material is applied but it's almost impossible to know what vertex is where. Would it be difficult to sort vertexes by what model they're associated with? This would simplify sorting out objects that should be permable and applying other flags. If not, I'm still content with what you've made.

Also on another note, when importing objects - more specifically the object material file (.mtl): There is a part that accounts for bump mapping which causes a nil error and corrupts the eqg archive.

It looks something like this (in the mtl file):

Quote:

newmtl terrain_object_alpha
Ns 10.000000000000
Ni 1.500000000000
d 1.000000000000
Tr 0.000000000000
Tf 1.000000000000 1.000000000000 1.000000000000
illum 2
Ka 0.587999999523 0.587999999523 0.587999999523
Kd 0.587999999523 0.587999999523 0.587999999523
Ks 0.000000000000 0.000000000000 0.000000000000
Ke 0.000000000000 0.000000000000 0.000000000000
map_Ka D:\C:\path_to_zone_source\obj_txr_alpha.png
map_Kd D:\C:\path_to_zone_source\obj_txr_alpha.png
map_bump C:\path_to_zone_source\obj_txr_alpha.png
bump C:\path_to_zone_source\obj_txr_alpha.png


I know it's this because if I remove the lines, it works just fine. So instead, I have to use the EQG Extractor to import the normals and add the texture normals into the material config (in the importer tool) but I have to do it in a specific order. If I already have the eqg file open with the zone importer while I am simultaneously importing new textures with the extractor; if I were to save the new normal modifier (in the importer) using the new texture - it saves the file as is and removes the textures I just imported. So, I have to import the textures and THEN open the eqg with the zone importer so that the texture files are there once I save my changes. It's no big deal but it caused some confusion when my normals weren't working. :p

knowom 06-19-2014 04:27 PM

Damn this looks great never really seen EQ looks so atmospheric in a outdoor zone the level of detail in terms of objects and the style is impressive.

I can imagine it populated with mobs hidden around different nooks and crannies of it shadowmen that path the jungle area's or ncps that are simply invisible or buff themselves with it and walking along triggering a trap that spawns mobs or does something else entirely poisons, snares, debuffs, or ports you ect.

Doing this same MOBA inspired map style, but with a mountainous with rocky terrain with lots of over passes bridges similar to like kingspass meets gfay (wood elf village with the bridges) would be incredible I bet. I love the potential all this adds to EQ it's new and refreshing it's kind of like experiencing the game new all over again at least in terms of exploring the new zone area's that are quite different in design which is entertainingly different.

Zaela_S 06-20-2014 04:22 AM

Quote:

Originally Posted by Packet (Post 231420)
Would it be difficult to sort vertexes by what model they're associated with? This would simplify sorting out objects that should be permable and applying other flags. If not, I'm still content with what you've made.

Technically they are all part of the single model glob that is the TER. The EQG game files don't have the concept of a submesh or anything like that, so I wouldn't be able to read boundaries from them beyond material associations. However, I might be able to whip something up for imported models only -- the .obj file does keep track of different named sections of geometry from the modeller (with the "Objects as OBJ Objects" export option from Blender, for example), so I could keep those in an external file and read from there. Probably worth doing; the list is just way way too long to look at as things are.

(Reminds me I need to add a way to set triangle flags for MOD models. Also I would be interested to see if EnvEmitter particles could be added to zone MODs through the weapon model importer and the particle data editor. Could probably have little fires, falling leaves, stuff like that.)

Quote:

Originally Posted by Packet (Post 231420)
Also on another note, when importing objects - more specifically the object material file (.mtl): There is a part that accounts for bump mapping which causes a nil error and corrupts the eqg archive.

Blah. The map_bump property is one of only two things it even reads from there, it ought to work :| Will have to take a look at that. I'm thinking of adding some kind of quick error dumping to the tool after that MOD import bug.

Zaela_S 06-22-2014 03:17 PM

In the meantime I got around to writing an export to .obj (it's under the "utility" menu).

The output files are a bit huge (~20mb) and it exports any referenced images at the same time. I dunno how to even navigate such huge models in Blender ;p Probably not useful to anyone but nice to have there for the sake of completeness.

Packet 06-23-2014 05:10 PM

Oh awesome! I'll be able to kidnap models and shove them places where they shouldn't be. *waits for Secrets to read this*


* I found another crash-on-import bug. Can I send you an obj file so that you can see it for yourself? It seems like it's directly related to UV's. If I unwrap a model and assign a new material to it (as of the latest version and a couple of versions ago), upon importing (as terrain, haven't tested .mod yet) it causes the "nil" error and corrupts the eqg.

Quote:

Originally Posted by Zaela_S (Post 231455)
Blah. The map_bump property is one of only two things it even reads from there, it ought to work :| Will have to take a look at that. I'm thinking of adding some kind of quick error dumping to the tool after that MOD import bug.

Actually, error logs would be amazing because I'm running into issues where certain models cause the entire import to fail and it's hard to pin point where the problem actually is. I have to manually remove everything first and then attempt imports until I get one that works.

Packet 07-14-2014 08:45 AM

Hey Zaela. Have you noticed any issues with UV Maps being off?

Zaela_S 07-14-2014 10:59 AM

Quote:

Originally Posted by Packet (Post 231865)
Hey Zaela. Have you noticed any issues with UV Maps being off?

I had noticed something when working on weapons. I used the 2.0 epics to test and noticed that the green gem texture on the necro one would end up in the wrong place after exporting and importing back in. Details on enchanter one were off all over as well.

Think I just figured it out while tinkering with a model viewer thingy. Apparently the V values in UVs need to be inverted, but only if they are positive. For whatever reason. I think I remember seeing something like that in the context of wld-based stuff, should have realized it sooner :|

Will try to get fixes up later today or tomorrow ... once I figure out what to do to cancel it out properly. Too tired to think right now ;p

edit: Might be something peculiar to DDS format, even just fixing that weirds up my PNG stuff. May just need to stop automatically flipping PNGs/whatever-non-DDSes on import. Hopefully.

Packet 07-15-2014 08:20 AM

Ahh good. I'm glad it's not just me exporting models with screwy uv's.

The 3ds max OBJ exporter allows me to modify the precision of the UV's which I assumed that was the likely culprit.

Zaela_S 07-15-2014 07:32 PM

Bit confusing to think about, but it's looking like the issue I was describing should only matter when converting DDS images to another format... I guess... although even then I'm not sure what would be needed to correct it yet ;p

I'm not sure what exactly your UV issue is, but if your UV values are extremely precise, something may be getting lost in translation. EQG uses 32bit floats, while I think the values in some of the material you gave me to test used 64bit doubles. Some of the least significant digits would be truncated to fit. Might try exporting with lower precision. At the end of the day it might be tough to get a huge texture pixel perfect over a huge mesh, though -- the bigger the image, the more precise the UVs have to be.

Zaela_S 07-16-2014 07:56 AM

In the meantime...

The material shader field now has a dropdown with all the combinations KLS listed available to select.

And the tool now has a barebones zone viewer. Use Viewer > Start Viewer to launch the independent viewer window after you have a zone loaded up in the tool. Does not account for alpha textures and whatnot. Also currently does not show placeable models, but I expect to add those in soon. May not load all textures/display everything correctly in every zone, probably some bugs, etc. Not particularly efficient either. And, of course, it only works with zone files that the tool understands, which is to say earlier EQG-based ones, and any S3D-based ones that you convert up with it.

http://i.imgur.com/SpjRWNy.png

Akkadius 07-16-2014 11:20 AM

I may not post, but I think this thread is cool to watch :)

501st 07-18-2014 08:35 PM

By Azura the things that happen when I'm MIA...

Just the npc thing alone, I remember wishing I could get modern npc models in older clients. In fact, Akkadius may specifically recall me crying about the Bellikos prior to Underfoot becoming a stable client...when the highest we had was SoD.

This is phenomenal. I need to get back into all this =X

Zaela_S 07-20-2014 06:34 AM

Quote:

Originally Posted by Zaela_S (Post 231455)
I might be able to whip something up for imported models only -- the .obj file does keep track of different named sections of geometry from the modeller (with the "Objects as OBJ Objects" export option from Blender, for example), so I could keep those in an external file and read from there. Probably worth doing; the list is just way way too long to look at as things are.

Went ahead and did this. Added a new tab called "OBJ Data": if you import a zone that has been exported with the "Objects as OBJ Objects" from Blender or equivalent, this tab will enable you to edit triangle flags by the "logical" divisions of the zone mesh from your modelling tool. For example, if you have a section of your zone mesh called "Hill" in Blender, there will be a listing for "Hill" in this tab which will refer to the same triangles. These are further subdivided by any materials that are applied to them; you can edit flags for only a certain material of a certain section of the mesh or for the whole section of the mesh regardless of materials.

tl;dr better triangle flag editor

http://i.imgur.com/rst4Ufd.png

Also added strafe movement to the zone viewer and stopped it wasting cpu time when the window doesn't have focus (probably shouldn't need to re-render at all unless the camera just moved now that I think of it... maybe next time).

Packet 07-22-2014 09:53 AM

Good work Zaela. I'll give an update soon on my progress. Again, thank you thank you thank you.

Edit: I noticed a bug some time ago that I figured (while not a big issue, can be easily replicated.). File->New EQG. then open the new EQG file you've just created.

You'll receive this error:

Quote:

.\gui/loader.lua:46: attempt to concatenate local 'ext' (a nil value)
stack traceback:
.\gui/loader.lua:46: in function 'LoadZone'
gui/main.lua:58: in function <gui/main.lua:49>
(tail call): ?
[C]: in function 'MainLoop'
gui/main.lua:255: in main chunk
Also, Zaela - I still get that "Attempted to index a nil value" error when trying to import a specific models as zone geometry. Is there some sort of triangle limit to .ter? Do you have any idea what it means by "nill value"? I mean, I understand something is missing but I'm trying to understand what is missing. I've manually looked through my obj file (as well as the mtl file) and I just don't see it.

3rd Edit:
I've narrowed the issue down to one of two possibilities. The UV mapping OR the texture itself. I have 3 models which are unwrapped via 3ds max and textured however, if I remove those 3 material entries from the mtl file - I get a successful import and the models come in without a texture. My next import, I will change the physical texture file out with one that already works to see if that's the difference. If the import fails, then this is likely because there is something wrong with the UV's themselves.

4th Edit:
Alas, swapping the textures (and I also tried swapping all of the material attributes from one that's working) resulted in the "nill value" error. I really don't know what's going on here. It seems to just not like the UV's on these specific models. I just don't get it. I unwrapped these models exactly the same way that I did everything else. Is there any logging or information that I can collect that'd tell me where to find said null value?

Zaela_S 07-22-2014 08:28 PM

Quote:

Originally Posted by Packet (Post 232119)
Edit: I noticed a bug some time ago that I figured (while not a big issue, can be easily replicated.). File->New EQG. then open the new EQG file you've just created.

There isn't really any reason to open a newly created EQG since there's nothing in it but an empty encoded directory. Will automatically be opened when you import something into it. Will fix it choking on contained files (or "files") with no extensions, though.

Quote:

Originally Posted by Packet (Post 232119)
Also, Zaela - I still get that "Attempted to index a nil value" error when trying to import a specific models as zone geometry. Is there some sort of triangle limit to .ter? Do you have any idea what it means by "nill value"? I mean, I understand something is missing but I'm trying to understand what is missing. I've manually looked through my obj file (as well as the mtl file) and I just don't see it.

3rd Edit:
I've narrowed the issue down to one of two possibilities. The UV mapping OR the texture itself. I have 3 models which are unwrapped via 3ds max and textured however, if I remove those 3 material entries from the mtl file - I get a successful import and the models come in without a texture. My next import, I will change the physical texture file out with one that already works to see if that's the difference. If the import fails, then this is likely because there is something wrong with the UV's themselves.

4th Edit:
Alas, swapping the textures (and I also tried swapping all of the material attributes from one that's working) resulted in the "nill value" error. I really don't know what's going on here. It seems to just not like the UV's on these specific models. I just don't get it. I unwrapped these models exactly the same way that I did everything else. Is there any logging or information that I can collect that'd tell me where to find said null value?

I haven't added logging or error dumps yet but I guess I'll do that next. I still have no issues with your stuff. Nil value error is pretty generic, but basically just means something that is expected to exist does not. Given what you've said it sounds like it is failing to find some textures listed in the .mtl file. The paths from that file are ignored, only cares about the file name which it looks for in the same folder as the .obj file. If your textures are all there, then I'm not sure what to say. Can only think of generic things: make sure the absolute path to each texture is less than 256 characters (old windows limit), maybe try making sure there are no spaces in the absolute paths (shouldn't matter).

Maybe I'll make it search in more places as well.


All times are GMT -4. The time now is 11:04 AM.

Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.