Jump to content
The Dark Mod Forums

Creating a light entity Def: how do we offset the light origin?


Bikerdude

Recommended Posts

@Biker: Indeed. I've just checked and light_center is not the light_origin. I never noticed that :D So creating a new entity def if you want the light origin to differ is really the only way it seems. However, I don't see the neccessity to have the same light to have different origins. That would only be inconsistent it seems, but that may just be me.

 

@Judith: The entity itself is not a light. You can see this by the entity not showing a light radius. The light comes from the attached entity (called flame). So if you want to change the texture for example you have to use set ... on. For example "set texture on flame" "lights/gathers/hammer_ornaments". You will see it works.

 

I agree that working with def_attached entities is not optimal yet. It would be nice if they would be previewable, and if one could alter settings on def_attached entities directly. But this would require code changes both in DR (at least a new gui that does something simlar like it's done in UE) and TDM (the way spawnargs are read or what gets understood by the engine might need adjustment). So it isn't impossible, but it is yet another objective on an already long list of stuff that "needs" implementation (according to what people assume needed) for a very limited amount of coders. And in this particular case we are not talking about something game-breaking, but more of a comfort function. So unless any coder consider it neccessary or anyone considering it neccessary becomes a coder, it is likely it will stay like this for a while, if not forever.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I'm not 100% sure of that, but for now I believe it's more about the perception, and the way the class tree is used, and not as much a coding problem. At least based on what I did so far. I basically created two simple defs, one is the light source and it inherits the atdm:light_base:

entityDef cor_lamp01_white_source
{
    "inherit"                "atdm:light_base"
    "AIUse"                    "AIUSE_LIGHTSOURCE"
    "lightType"            "AIUSE_LIGHTTYPE_ELECTRIC"
    "extinguished"            "0"
    "light_radius"            "256 256 256"
    "_color"                "0.502 0.502 0.502"
    "texture"            "lights/do/cor_lamp01_pulse"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And the second is the model, which inherits the cor_lamp01_white_source (not func_static or anything else):

entityDef cor_lamp01_white
{
    "inherit"    "cor_lamp01_white_source"
    "model"        "models/do/cor_lamp01.ase"
    "editor_displayFolder"    "Lights/Electric"
    "light_center"        "-48 0 -32"
    "skin"                    "cor_lamp01_wht"
    "skin_lit"                "cor_lamp01_wht"
    "skin_unlit"            "cor_lamp01_unlit"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And it works just like in the Unreal class tree. The cor_lamp01_white entity has a light radius, and lets me edit the light properties in the map, even though it's not a light. The whole thing with def_attached seems like overcomplicating things and not using the potential of class tree system.

Edited by Judith
Link to comment
Share on other sites

However, I don't see the neccessity to have the same light to have different origins.

Imho its down to a few reasons -

  • having the shader projected correctly inline with where the light would appears to be coming from - eg so faux shadows from a lantern are under the light emitting part of the lantern etc.
  • due to the way the diffuse layer on some of our textures reacts to light that very close to the surface of the brush/patch its on(its not illumintaed very well), the mapper is forced to move the center and/or the origin further away from said surface.
  • sometimes the mapper want to make sure that the radius of lights don't overlap and a quick and dorty trick is to move the origin around/away and make sure the center is in the middle of the model etc - to give the illusion to the player the area is lit correctly while at the same time not suffer from any perf issues due to overlapping lights
Link to comment
Share on other sites

entityDef cor_lamp01_white
{
    "inherit"    "cor_lamp01_white_source"
    "model"        "models/do/cor_lamp01.ase"
    "editor_displayFolder"    "Lights/Electric"
    "light_center"        "-48 0 -32"
    "skin"                    "cor_lamp01_wht"
    "skin_lit"                "cor_lamp01_wht"
    "skin_unlit"            "cor_lamp01_unlit"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And it works just like in the Unreal class tree. The cor_lamp01_white entity has a light radius, and lets me edit the light properties in the map, even though it's not a light. The whole thing with def_attached seems like overcomplicating things and not using the potential of class tree system.

But, are you able to move the 'light_origin' (not light_center)around in DR..?

Link to comment
Share on other sites

I'm not 100% sure of that, but for now I believe it's more about the perception, and the way the class tree is used, and not as much a coding problem. At least based on what I did so far. I basically created two simple defs, one is the light source and it inherits the atdm:light_base:

entityDef cor_lamp01_white_source
{
    "inherit"                "atdm:light_base"
    "AIUse"                    "AIUSE_LIGHTSOURCE"
    "lightType"            "AIUSE_LIGHTTYPE_ELECTRIC"
    "extinguished"            "0"
    "light_radius"            "256 256 256"
    "_color"                "0.502 0.502 0.502"
    "texture"            "lights/do/cor_lamp01_pulse"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And the second is the model, which inherits the cor_lamp01_white_source (not func_static or anything else):

entityDef cor_lamp01_white
{
    "inherit"    "cor_lamp01_white_source"
    "model"        "models/do/cor_lamp01.ase"
    "editor_displayFolder"    "Lights/Electric"
    "light_center"        "-48 0 -32"
    "skin"                    "cor_lamp01_wht"
    "skin_lit"                "cor_lamp01_wht"
    "skin_unlit"            "cor_lamp01_unlit"
    "shaderparm3"    "0"
    "shaderparm4"    "0"
}

And it works just like in the Unreal class tree. The cor_lamp01_white entity has a light radius, and lets me edit the light properties in the map, even though it's not a light. The whole thing with def_attached seems like overcomplicating things and not using the potential of class tree system.

In your example case you are using an electric lamp. If you check the entities shipped with DR, you'll see that most lights of that sort do not use def_attach. Def_attach is normally used for flame lights, like candles or torches. The reason is that the light has its own model, which is not the model carrying the light, but the flame itself. So you have a model that burns, like a torch or a candle, and the light entity which uses a particle as model, the actual flame.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

BTW: extinguished doesn't make much sense on electric lights ;)

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Wouldn't it be easier to just offset the position of the light to match the attached particle, and still have the ability to change light properties in DR?

 

And "extinguished" "0" is actually taken from atdm:static_electric_light_lit_base, as that light source was supposed to play similar role.

Link to comment
Share on other sites

Indeed. But it is more suppossed to be used on flame lights. Electric ones normally use start_off. Although both might work.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Wouldn't it be easier to just offset the position of the light to match the attached particle, and still have the ability to change light properties in DR?

It would at least be a different approach. Easier is relative. :) Nothing prevents anyone from doing it that way when creating there own light entities.

 

EDIT: One thing that might stand in the way of doing it like this is the script object used by combined light entities (tdm_light_holder). It is possible that it needs to be altered to allow such a setup, if it doesn't already.

  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

IMO it would be consistent with how it's used in other engines, i.e. you want to create a light, first and foremost, right? So you go from a general light class > light with certain properties > certain light with certain model representation. From general to narrow. Not from a func_static to certain particle to certain light. The second approach forced you to create workarounds that make it all more complicated and longer.

 

Don't mean to sound rude, but IMO the whole goal of TDM was to escape from all the quirks and workarounds of Thief Deadly Shadows, not to exchange them to quirks you know and understand, because you created them yourself ;)

Link to comment
Share on other sites

 


Not from a func_static to certain particle to certain light.

That isn't really the workflow. The entity is a func_static with a light entity attached to it. The latter uses a particle as a model.

 

Your approach as I understand is would be to use a light with the func_static model and attach a particle to it. In that case, all you do is to shift the light settings from the attached to the master entity. However, everything related to the particle would still be on the attached entity. So we would probably lead the same discussion, just in regards to the particle settings. And it wouldn't be consistent at all.

 

(Note that this also only relates to entities that are light holders, not lights themselves.)

 

I completely understand where you are coming from, but to make it really consistent all settings should be adjustable on the master entity, so both light and particle settings. This doesn't seem possible to me at the moment (except via the usage of set ... on), as an entity cannot have two models (the torch and the particle for example).

 

And to be honest, I don't really see set ... on as a workaround. It is exactly intented for that purpose. It would be a workaround if you would use something that is intented to do something different in the first place. This is not the case here.

 

There are several wiki articles handling attached and combined light entities, and they also cover the usage of set...on. It might not be the most elegant solution, but it does what it should. And why should there be any neccessity to be consistent with other engines? What is the issue on using the editor and engine the way it is intented to be used?

  • Like 2

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

There is no need to be compatible with other engines just as a principle, but you can see that they build the structure better, and prioritse functions according to users' needs. With light entities, you need to be able to change light properies often, that's a priority. Particles can be attached e.g. to a helper, or just in relation to a static model, and tweaked in particle editor, and that's it, for most cases. The main goal is always speed and ease of use. As you know, mapping is already long and complicated process, so everything that speeds it up, even just a little, is invaluable. That goes for both using the editor/engine and amount of things or parameters to keep in mind while mapping.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...