Jump to content
The Dark Mod Forums

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


Bikerdude

Recommended Posts

So I'm creating a new light entity for Bhm, but rather annoyingly the light entity is located where the original of the models is.

 

Looking at at a lot of the stock light entities and I can see they all suffer from this issue, and this results in the light shader is offset from the model when for example when we have a lantern with four panes of glass and the mapper wants to then use a mapping shader eg "lights/tdm_lanternlight". The center of the shader wont be directly under the part of the model with the glass panes etc.

 

So my question is can the position/offset of the light entity (not the light_center) be defined in the def..?

@Biker: What issues? I didn't get it it seems

Sorry I probably wasn't clear enough with my initial post.

 

The attached snippet shows a typical electric light source, and you can see the light origin is the exact same location as the origin of the model.

 

post-496-0-63233400-1524648163_thumb.jpg post-496-0-05567800-1524648170_thumb.jpg

 

The issue's are -

  • if I dont use def_attatch I can't change or move the light_origin, which means for example a shader with a pattern (tdm_lantern) with directly under the origin of the light, not the light_center which idealy where you would want it.
  • So then a mapper would then use def_attach so he/she could change the location of the light_origin eg
    "def_attach"                         "light_candleflame_unlit"
    "pos_attach"                         "flame"             // At the attach point called "flame"...
    "attach_pos_name_1"          "flame"             // ... which is defined here.
    "name_attach"                      "flame"            // Give it a name to pass along spawnargs
    "attach_pos_origin_1"      "0 0 10"          // Offset the origin of the light/flame X number of units in the Z direction 
    "light_center"                        "0 0 20"          // Offset the center of thelight/flame X number of units units in the Z direction
    "light_redius"                        "130 130 130"          // size of the light radius
    "texture"                                "lights/biground_candleflicker_shadow"  //shader for the light souce
    "_color"                                 "0.80 0.6 0.23"    //colour of the light souce

And now I have just realised what i was doing wrong, which was causing TDM to ignore my "light_radius" in-game. I was using "light_origin" instead of "attached_pos_origin" and this was because I thought it would be the same nomenclature as 'light_center' and 'light radius'.

 

The issue with def_attach is that the mapper can't then change the origin in DR, its has to be done in the .DEF file for that entity. Or they can force change the setting in DR using the following args -

// Flame

"set light_radius on flame" "100 100 100"
"set color on flame"
"set s_volume on flame" "-20"
"set attach_pos_origin on flame" "0 0 0"
"set _color on flame" "0 0 0"

// light

"set light_radius on light" "100 100 100"
"set color on light"
"set s_volume on light" "-20"
"set attach_pos_origin on light" "0 0 0"
"set _color on light" "0 0 0"

As some have mentioned in this thread, it would be nice to be able to change the above setting in DR using normal methods, not args. I guess the only way yo do this is for DR to create new definitions? like it does when you modify or create new particles?

Edited by Bikerdude
Link to comment
Share on other sites

So I'm creating a new light entity for Bhm, but rather annoyingly the light entity is located where the original of the models is.

 

Looking at at a lot of the stock light entities and I can see they all suffer from this issue, and this results in the light shader is offset from the model when for example when we have a lantern with four panes of glass and the mapper wants to then use a mapping shader eg "lights/tdm_lanternlight". The center of the shader wont be directly under the part of the model with the glass panes etc.

 

So my question is can the position/offset of the light entity (not the light_center) be defined in the def..?

 

If the light entity is spawned in you could set the origin of the attachment. So for example for the entity "atdm:sconce_2candles_rigid" you could just change the spawnarg "attach_pos_origin_1" to whatever new origin you would like which would change the position of the actual light entity on the object when it gets spawned in.

Link to comment
Share on other sites

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

As many as you want, I guess. I never read of any limit. But just to make sure that I understand you. Are you planning to bind 12 different lights to one entity? Because, if so, that would be a very bad idea.

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

As many as you want, I guess. I never read of any limit. But just to make sure that I understand you. Are you planning to bind 12 different lights to one entity? Because, if so, that would be a very bad idea.

What I have is

I need to offset the origin of the light so its below the model and the light center is in line with the bulbs. Then def attached all the emitters to the bulbs.

Edited by Bikerdude
Link to comment
Share on other sites

That might eat up performance pretty quick too, both because of number of emitters and particles generated, and/or because of transparency overdraw. A lot depends on how well the emiter is made. One or two static particles would probably be fine, but I imagine placing 2 or 3 such chandeliers in a scene might cause a slowdown.

 

Edit: too slow :) one particle would probably be a good solution.

Edited by Judith
Link to comment
Share on other sites

one particle would probably be a good solution.

I guess a single custom particle would cleaner in the def at-least.

 

Well rather annoyingly, the new "func_bulb" entity appears in game just fine when I place it in DR - but is not appearing, def_attaching on the model.

Edited by Bikerdude
Link to comment
Share on other sites

I created a single custom particle, as this cuts down the on the entity count and for now I am just gonna place the new "atdm:func_chandelier_emitter" entity in the map, I cant figure out why the bloody thing wont def_attach.

 

post-496-0-54932800-1524151421_thumb.jpg

 

The only other issue is the light entity at spawn time is on, but is not using the lit skin at spawntime. Turning it off then on again fixes that, any one got any pointers..?

 

 

 

entityDef atdm:func_chandelier_emitter
{
"inherit" "func_static"
"editor_color" "0.875 0.878 0.804"
"editor_mins" "-12 -12 -12"
"editor_maxs" "12 12 12"
"editor_rotatable" "1"
"cycleTrigger" "0"

"editor_displayFolder" "Func"
"editor_usage" "custom light bulb emitter for bhm chandelier"
"editor_bool start_off" "0" //if set to 1, particle system will not be visible on spawn."

"editor_setKeyValue model" "tdm_chandelier_12_bulb.prt" // the key value to be set when this entity is created

"solid" "0"
"noclipmodel" "1"
"spawnclass" "idFuncEmitter"
"start_off" "0"
}

entityDef atdm:bhm_chandelier_01
{
"inherit" "atdm:static_light_lit_base"
"model" "models/darkmod/lights/non-extinguishable/bhm_chandelier_01.lwo"
"editor_setKeyValue model" "models/darkmod/lights/non-extinguishable/bhm_chandelier_01.lwo"
"editor_displayFolder" "Lights/Model Lights, Static/Switchable/Electric/Indoor"

// attach the main light

"def_attach" "light"
"pos_attach" "light" // At the attach point called "light"...
"attach_pos_name_1" "light" // ... which is defined here.
"attach_pos_origin_1" "0 0 -160" // Offset the position of the light
"light_center" "0 0 60" // Offset the position of the light center
"texture" "lights/brightround"
"editor_usage" "A ceiling mounted electric lamp with a fancy design. Can be switched on/off."
"light_radius" "320 320 320"
"_color" "0.48 0.38 0.27"

// attach the 12 point func_emitter

// "def_attach1" "atdm:func_chandelier_emitter"
// "pos_attach1" "emitter" // At the attach point called "emitter"...
// "attach_pos_name_2" "emitter" // ... which is defined here.
// "attach_pos_origin_2" "0 0 0" // Offset the func_emitter


// skin and shadows

"noshadows" "0"
"noshadows_lit" "1" // no shadows from the model when lit

//"skin" "lights/bhm_chandelier_unlit"
"skin_lit" "lights/bhm_chandelier_lit"
"skin_unlit" "lights/bhm_chandelier_unlit"

"frob_action_script" "frob_light_holder_toggle_light"

}

 

 

Edited by Bikerdude
Link to comment
Share on other sites

Why don't you inherit the emitter from func_emitter then from func_static?

Is there any console output that might be of use to hunt down the error?

Is the chandelier moving?

 

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

Why don't you inherit the emitter from func_emitter then from func_static?

Is there any console output that might be of use to hunt down the error?

Is the chandelier moving

Tried that, dosent work in DR or in TDM, had to create a custom "func_emitter" and a new particle.

Didnt think to check, will a normal console output show anything though..?

nope, static.

 

Link to comment
Share on other sites

 


Tried that, dosent work in DR or in TDM, had to create a custom "func_emitter" and a new particle.

No, I've meant the following.

 

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" // <<<<------------------------------
    "editor_color"                    "0.875 0.878 0.804"
    "editor_mins"                    "-12 -12 -12"
    "editor_maxs"                    "12 12 12"
    "editor_rotatable"                "1"
"cycleTrigger"          "0"
    
    "editor_displayFolder"                "Func"
    "editor_usage"                        "custom light bulb emitter for bhm chandelier"
    "editor_bool start_off"                "0" //if set to 1, particle system will not be visible on spawn."
    
    "editor_setKeyValue model"         "tdm_chandelier_12_bulb.prt" // the key value to be set when this entity is created
    
    "solid"                        "0"
    "noclipmodel"                    "1"
    "spawnclass"                    "idFuncEmitter"
    "start_off"                    "0"
}

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

Func_emitter is only a rough wrapper which starts working once additional spawnargs (like the prt to use) has been specified. When defining a new entity you do exactly the same. Inherit gets the entity you want to start off with (in your case func_emitter), and then you just add the spawnargs needed. That's the whole point of inheritance. Your definition should actually look like this

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

  • 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 super proficient in entity classes yet, but IIUC, it should work like actor class tree in Unreal and other engines: you start from general and go to specific. So from light to a certain light, then to light with certain model, and then to light with certain model and certain particle.

Link to comment
Share on other sites

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

Fair enough, will give that a try.

Edited by Bikerdude
Link to comment
Share on other sites

I'm not super proficient in entity classes yet, but IIUC, it should work like actor class tree in Unreal and other engines: you start from general and go to specific. So from light to a certain light, then to light with certain model, and then to light with certain model and certain particle.

That is basically how it works. The whole idea behind this concept is that you try to keep the amount of repetition as low as possible. This basically comes from programming, where several types of constructs (called structs or classes/objects in modern programming languages) may do similar things. In that case you would have to write the same piece of code over and over agian. Instead you define a basic class that implements all the features that are shared by all your constructs, and in the latter you only have to specify what is specific to them.

 

The inheritance in entity definitions work the same. For example you create a basic entity definition for ai, which specifies all the things that are common among all ai. This is not a working ai yet, as lots of imformation are missing (like the specific model to use, the vocal set or whatever), but you have a blueprint for all your ai now. When you then create a specific ai, like a builder guard, you let it inherit from your base class (it now has all the features and properties specified there), and only add what is needed and may change what differs from the default values set in the base class. This way you can save a lot of time. In addition, if you want to make a change to all ai, like changing the scriptobject to use, you only have to make that change in the base class, instead of doing so for all dozens of ai entities you may have defined. All ai will inherit the change from the base class (hence that naming).

 

https://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)

https://www.youtube.com/watch?v=ajOYOxCanhE

  • 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

entityDef atdm:func_chandelier_emitter
{
    "inherit"                    "func_emitter" 
    "model"         "tdm_chandelier_12_bulb.prt"  
}

That's it. All other values (like spawnclass, starts_off etc...) are inherited from func_emitter and only need specification if their values should differ from the ones specified in the base entity class.

Obs your a little star, as soon as I changed to the above and def_attched it to the new light entity it worked in-game. I had just been overcomplicating things, nice one fella!

Edited by Bikerdude
Link to comment
Share on other sites

Thou art welcome, Sir Dude :)

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

The only other issue is the light entity at spawn time is on, but is not using the lit skin at spawntime. Turning it off then on again fixes that, any one got any pointers..?

@Obs, got any ideas or pointers on the the above..?

Edited by Bikerdude
Link to comment
Share on other sites

Use the skin spawnarg. (The one you've commented out ;) )

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

skin is the spawnarg used by the engine to determine whether and what skin should be used. skin_lit and skin_unlit are used by the scriptobject (tdm_light_holder). The script changes the skin once the light status changes. IIRC it doesn't check for the initial state after spawn and choose the proper skin. Might be worth tweaking that in the future so that the skin spawnarg becomes unneccessary on entities using said scriptobject.

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

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  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • 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
×
×
  • Create New...