[Mark]

I'll unparallax the sky in that area and look to be sure.

[Kyanos]

Drek, on 19 June 2016 - 12:07 PM, said:

third or fourth edit; I'm positive the dummytile code is set here for something generic like 32 x 32 and the lights are just missing the sprite itself, so the model is not catching lights, make the sprite coded to be the same size as the model. (no matter how much you use models the engine will always be sprites at the core)

Posting this again in case you missed it, quick edits and page turning and all...

Using dummytile, define the sprite to be close to the same size as the model in game.

[Mark]

That outside area has all ceilings raised way up high. No interference from there.

DREK. I'm pretty sure it is. I will double check. BRB

Yes. It is set to close to model size in the map. Even though I did it before I also tried wall and floor alignment along with setting one sided on and off.

[Kyanos]

Mark., on 19 June 2016 - 12:32 PM, said:

That outside area has all ceilings raised way up high. No interference from there.

DREK. I'm pretty sure it is. I will double check. BRB

Yes. It is set to close to model size in the map. Even though I did it before I also tried wall and floor alignment along with setting one sided on and off.

Ok try this. Re export the model, with the origin 0,0,0 near center, then in the map pg up the sprite so that model is back where you want it, but the sprite is up where the lights hit it.

[Mark]

I'll give that a try since the origin of the model right now is at the bottom center.

[Kyanos]

It's half grasping at straws... But it might just work, good luck.

[Mark]

No luck with that repositioning the model.

Another oddity is that global illumination when firing a weapon lights up the model. It just doesn't want to respond to the point lights.

EDIT: I was about to replace the model with another one but then I remembered early on, maybe a month ago or more, I tried that already. The replacement lit up which led me to believe at that time it was a model problem. But from all the extensive testing I have done so far I still can't come to a 100 percent conclusion. The model is complicated enough that I don't want to make our guy rebuild it from scratch.

My brain hurts.

[Danukem]

Mark., on 19 June 2016 - 01:01 PM, said:

No luck with that repositioning the model.

Of course not, because the underlying sprite is what determines collision and hitscan and all that good stuff. Earlier you said that the lights affect it when the model is raised up. Pretty clearly, then, you have a positioning problem. But again, changing the model will not make any difference. I would start by turning models off in the menu (leave polymer on), and see where the actual sprite is. If it's a dummy tile, it will appear as a black square, otherwise it will be whatever art you have on that tile. You want the sprite to be hit by the lights. Make sure that the area taken up by the sprite is as close as possible to the area taken by the model.

EDIT: Here's an example of what could be happening. Let's say that the model definition has a zadd offset to make it appear higher. If that's the case, then the sprite could actually be underground while the model appears to be on the ground. If underground, the light doesn't hit it, so...

[Mark]

No positioning in the def file and Drek mentioned checking the dummytile tile sprite. It is there in its proper place in the game and very close to actual model size. But again I have to ask why it lights in Mapster but not the game. That is the most frustrating part. Other than the maxlightpasses I can't think of any other settings that could make that difference between the 2

[Kyanos]

Mark., on 19 June 2016 - 03:09 PM, said:

No positioning in the def file and Drek mentioned checking the dummytile tile sprite. It is there in its proper place in the game and very close to actual model size. But again I have to ask why it lights in Mapster but not the game. That is the most frustrating part.

Trooper Dan is right though. The lights worked when you moved the sprite. Put the sprite there again then reposition the model via def code.

[Mark]

I've got nothing to lose. I'll try it. Even though it doesn't explain why Mapster displays it properly now. BRB

[Mark]

To use the zadd command do I just take the build z number where the model was placed and then add or subtract the amount in build z units to move?

For instance I have the model placed at -110080 and need it moved up to -82432 so I zadd 27648? That doesn't seem right because HRP models have zadd's in the single and double digits

EDIT: I guess I'll just start entering random numbers to find out. The wiki doesn't help any.

[Mark]

Something worked out right for once today. I made a guess that zadd might be how many pgup clicks so I entered 30 cause I knew it was somewhere around that many. It raised the model up into place but still did not light up.

I think I'm giving up for the day on this. Thanks everyone for the help.

[Tea Monster]

I've tried making a simplified model that is very low poly, but is the same size and shape of the original. I've even tried deffing out the spec and normal maps and no joy. So it is unlikely to be a model problem.

I've also tried reducing the number of lights to just one. Still no lights

[Plagman]

Send me your low-poly md3 and I can take a quick look.

[Plagman]

OK, so there was one EDuke32 regression (eg. when I wrote the code it worked properly, but unrelated changes broke it; this is why I hate changing code just because, BTW) that made lights affects some models from farther than they should, which is now fixed, make sure to update to a revision after 5805.

However there's also a lot of user/asset error in the various issues that got reported here:
- Make sure your normals are good; a lot of MD3 exporters out there disregard normals entirely, so run everything through nPherno's compiler if you have to. ALL LIGHTING won't work properly if normals aren't correct, not just normal maps or specular or whatever. Also be mindful of nPherno's liberal implementation of smooth shading when there's no UV seams to latch onto; on very simple models with huge faces and sharp edges this'll distort your lighting too.
- After the fix, one of the models that TM had (cinema facade) is affected by about 12 lights from the map, potentially more during gameplay because of dynamic lights. This means that the default light pass number will make a lot of lights not affect it. Mapster32 queues lights in a different order than EDuke32, so results can vary between the two. PLEASE try setting max light passes to a high number through the cvar to rule that out before reporting a bug and wasting people's time. Make use of the light priority system if you have lights right next to a map model that really should always affect it.

[Mark]

thats odd. One of the many tests I made was deleting 7 of the other closest lights near the sign and it still wasn't lighting. And I also had maxlightpasses set up to 9. But when reading your message its possible that lights that did not have a radius to reach the model may still have been counted as affecting the model. I will check out the latest changes. Thanks. BTW, since it worked in Mapster i'm curious as to what he maxlight default setting is.

[Plagman]

There were 22 lights affecting the facade with the buggy EDuke32 build, and in the game the 4 lights you care about were last in the model's light list. As I said Mapster and EDuke32 add the lights in a different order, it's not a max light difference.

[Danukem]

Mark., on 21 June 2016 - 03:44 AM, said:

BTW, since it worked in Mapster i'm curious as to what he maxlight default setting is.

According to the wiki, the default value is 5. Plagman said that mapster queues lights in a different order from eduke32, so there you go. I'm going to suggest that when you place lights, start by making them the lowest or at least middle priority, then use high or highest priority only when needed. I'll bet if you go through the map and knock down the priority of every single light except the problem ones, they will start to work.

[Mark]

After loading up the newest Eduke version all lights are working. Is setting a light priority a con thing or a setting of the sprite using F8? there are so many features documented and not that I am ignorant of.

[Danukem]

Mark., on 21 June 2016 - 12:23 PM, said:

After loading up the newest Eduke version all lights are working. Is setting a light priority a con thing or a setting of the sprite using F8? there are so many features documented and not that I am ignorant of.

Oh dude...that's so basic. In fact if you look at the very first post in the EDuke32 and Polymer thread that I started several years ago [EDIT: May 2009 to be exact], it explains how to do this. It's controlled by the transparency level on the light SE. Solid is highest priority, trans level 1 is lower priority, trans level 2 is lowest.

[icecoldduke]

Trooper Dan, on 21 June 2016 - 02:36 PM, said:

Oh dude...that's so basic. In fact if you look at the very first post in the EDuke32 and Polymer thread that I started several years ago [EDIT: May 2009 to be exact], it explains how to do this. It's controlled by the transparency level on the light SE. Solid is highest priority, trans level 1 is lower priority, trans level 2 is lowest.

Placing lights in build is very counter intuitive vs other engines. Opening up F8 and then trying to remember how all that shit gets remapped is awful. When F8 is pressed, and the lotag is a light, light editable values should come up.

[Mark]

I guess throughout the years of mapping I never considered a light I placed to be anything other than a priority. Its meant to light where I placed it and not take a back seat to another. Now that I know about it, it might come in handy some day. But right now I'm not clever enough to find a use for the setting.

[Danukem]

Mark., on 21 June 2016 - 02:53 PM, said:

I guess throughout the years of mapping I never considered a light I placed to be anything other than a priority. Its meant to light where I placed it and not take a back seat to another. Now that I know about it, it might come in handy some day. But right now I'm not clever enough to find a use for the setting.

It's potentially important when you consider that the typical player will be using the default light settings, meaning a max of 5 lights per surface. As a starting point, I would make all spotlights the highest priority, make powerful point lights (range > 5000ish) medium priority, and weaker point lights lowest priority. You could even apply those settings to a whole map by running a little mapster script. Then you can make individual adjustments as needed.

[Kyanos]

icecoldduke, on 21 June 2016 - 02:41 PM, said:

Placing lights in build is very counter intuitive vs other engines. Opening up F8 and then trying to remember how all that shit gets remapped is awful. When F8 is pressed, and the lotag is a light, light editable values should come up.

This argument can be made for all the se sprites (that came with the game)

Also this issue can be dealt with nicely enough via m32 script, like I once tried (and got a decent amount of it done, more than se's)

Drek, on 04 July 2014 - 08:11 PM, said:

So the hardest part was condensing nukeys good sentences and paragraphs into small quotes, I crammed a ton of info into 10 quotes per sector effector sprite lotag.

help.m32.txt

It took a ton of searching for me to find this stupid thing... is it worth it's own thread and maybe updates??
edit; I just went over the old script I linked and see that I did do lots more to it here, but never shared it with you good folks. I'll make a thread later and update it

[Mark]

In my autoexec.cfg I have the number raised above default.

But since the eduke fix there won't be a lot of close by lights fighting for display in the same area so priority doesn't seem useful. But I get what you mean. If I had a room full of point lights and I wanted to project something on a wall with a spotlight I would give priority to the spotlight

[Tea Monster]

I had no clue there was any kind of priority system on lights, then again, my strength isn't Mapster. Secondly, I too removed all but one of the lights that was shining on the model in question and it didn't fix the problem. Anyway, it's fixed, thank you for chasing that down and getting it sorted.

Models exported from Blender had the correct normals when exported as FBX or OBJ. When exported as MD3, things went wrong. We had thought that it might be a normals issue. We were not trying to 'Waste your time' as you put it. We tried multiple ways of trying to fix a normal's problem. The model was exported from Blender as an FBX and an OBJ and read fine in Marmoset. That OBJ was then imported to both Noesis and Misfit 3D and exported as an MD3 and displayed the error we reported. I have even used NPherno's compiler to fix the normals.

We also experienced a lot of variation when exporting models from any of the exporters. Some would work fine in a test map we made. Those same MD3 files would not display correctly in our main map. I mentioned that Steeevie's Hydrant has that issue as I saw that in the test map that I sent to you. I just checked the main map to confirm, and it dosen't have the sidedness issue there, though it is in the test map, with the same MD3 file.

So we did do our homework before asking for help. What did you use to test the normals on the MD3 at your end?

[Mblackwell]

http://wiki.eduke32.com/wiki/SE49
http://wiki.eduke32.com/wiki/SE50

It says right on the page for lights that there's a priority system.

[icecoldduke]

Mark., on 21 June 2016 - 03:43 PM, said:

In my autoexec.cfg I have the number raised above default.

But since the eduke fix there won't be a lot of close by lights fighting for display in the same area so priority doesn't seem useful. But I get what you mean. If I had a room full of point lights and I wanted to project something on a wall with a spotlight I would give priority to the spotlight

How many shadow casting lights are you guys using in a single area?

[MusicallyInspired]

It's nothing more complicated than choosing which lights you want to be more important if the renderer starts having to turn some off.