Jump to content


Photo

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


62 replies to this topic

#26 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20166 posts

Posted 23 April 2018 - 06:00 AM

Ok so just discovered that use def_attache broke 2 things -

  • It stopped me being able to treat & manipulate the entity like a light in DR
  • Its ignored the light_radius arg, as in it just set 320 320 320.

Is there really no way to move the origin of the light source without using def_attach..? As it stands with all model based light entities, the light entity is always stuck at the origin of the model.


Edited by Bikerdude, 23 April 2018 - 06:04 AM.


#27 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1582 posts

Posted 23 April 2018 - 06:20 AM

It stopped me being able to treat & manipulate the entity like a light in DR.

 

I thought this is supposed to be a normal thing, and that's why I don't use custom light entities. Light source gets invisible, you can't see its radius and you can't change it via spawnargs.



#28 Springheel

Springheel

    Creative Director (retired)

  • Admin
  • 37376 posts

Posted 23 April 2018 - 09:12 AM

You can change it via spawnargs, though it's true it's invisible in DR.  I forget the specific syntax at the moment but I've done this in most of my missions.


TDM Missions:   A Score to Settle   *   A Reputation to Uphold   *   A New Job   *    A Matter of Hours
 
Video Series:   Springheel's Modules   *   Speedbuild Challenge   *   New Mappers Workshop  *   Building Traps

#29 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8980 posts

Posted 23 April 2018 - 09:20 AM

Right, there are a few DR feature requests in this area I believe.

Making DR understand combined entities and allowing DR to see and manipulate the light_center (instead of the origin of the light).
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#30 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20166 posts

Posted 23 April 2018 - 10:07 AM

I forget the specific syntax at the moment but I've done this in most of my missions.

Would be curious to see how you did it, got a specific example?

Making DR understand combined entities and allowing DR to see and manipulate the light_center (instead of the origin of the light).

Yes this would be extremely useful in this instance, got number for the trackers as I dont remember seeing this request..?



#31 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8980 posts

Posted 23 April 2018 - 10:32 AM

There is a very old tracker about combined light entities:

http://bugs.thedarkm...view.php?id=994

I couldn't find anything about the light_center but I will create one after testing the current DR
if you don't get to it before me.
  • Bikerdude likes this
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#32 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20166 posts

Posted 23 April 2018 - 11:04 AM

Thanks fella.



#33 nbohr1more

nbohr1more

    Darkmod PR, Wordsmith

  • Development Role
  • PipPipPipPipPip
  • 8980 posts

Posted 23 April 2018 - 11:44 AM

Hmm.

If I read the combined light entity article right, the other option is to create several distinct entities
then use "bind" rather than def_attach. That allows you to see all the bound entities in DR. In the article
it lists the disadvantage of moving them together being a problem but now you can group entities in DR so
that disadvantage is mostly gone. In fact, you could just make an emitter entity and add it to a DR group
with the light model if it's stationary.
Please visit TDM's IndieDB site and help promote the mod:

http://www.indiedb.c...ds/the-dark-mod

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

#34 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1582 posts

Posted 23 April 2018 - 11:50 AM

You can change it via spawnargs, though it's true it's invisible in DR.  I forget the specific syntax at the moment but I've done this in most of my missions.

 

Usual spawnargs don't seem to work. Also, if the whole "class tree" thing is to make any sense, those light properties should be inherited and editable when you tick the Show inherited properties checkbox, just as it worked in Unreal and T3Ed. Right now it looks like this:

 

obraz.png

 

As you see stuff like light radius isn't even there, you can't change brightness/color, some things are repeated in active current-level properties, etc. Right now it's pretty confusing.


Edited by Judith, 23 April 2018 - 12:25 PM.


#35 Destined

Destined

    Advanced Member

  • Member
  • PipPipPip
  • 1560 posts

Posted 23 April 2018 - 03:41 PM

There is a Wiki page about combined light entites. I think you will find what you are looking for there. Especially, the section "Setting spawnargs". There is an example on how to change the colour, but I don't see why it should not be the same with the light radius...


Edited by Destined, 23 April 2018 - 03:42 PM.


#36 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1582 posts

Posted 23 April 2018 - 04:08 PM

Yup, the "set sth on flame" spawnarg works, although that's more like a workaround, not a solution (i.e. you can't edit the color values with the usual color menu, etc.).

 

It's interesting that this hasn't bothered anyone since... 2008, apparently. I haven't played with other entity classes and their dependencies yet, but if it works like that, then the usability of the whole system is kind of limited.



#37 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5681 posts

Posted 23 April 2018 - 04:39 PM

Manipulation is done via set as pointed out above. Normally, you would create a custom light definition where you specify the settings required and attach that one. It is obvious that using the spawnargs directly can't work, because if you have several entities attached how should the engine know on which one you want to alter the spawnarg.

 

It is not optimal that DR doesn't recognize the set command in a way that let you use specific menus like the color menu or that def_attached entities aren't previewed at all. But as most spawnargs are text or numbers only you get used to it when working with them long enough. Personally I don't have any issues with that.


FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#38 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20166 posts

Posted 23 April 2018 - 04:46 PM

As you see stuff like light radius isn't even there,
you can't change brightness/color, some things are repeated in active current-level properties, etc.
  • Yes it is, looked at the inherited line "atdm:lamp_wall_gasflame03_unlit"
  • Its simple enough -
    • if the new light entity, in my case a chandelier made my dram uses inherited light properties it works as you would expect In DR, you can edit all the arg's (change the radious the origin, etc etc)
    • if the new light entity uses def_attach method then the mapper has to manually adjust the args under inherited properties in the entity viewer.

What I found with the second option is even when I set the light_radious manually the enetity/engine was ignoring my setting, so I had to go the first option and use a second light entity - and then switch both of them along with a func_emitter from a nearby switch.



#39 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1582 posts

Posted 23 April 2018 - 04:48 PM

One of the most useful features of the entity classes system is ability to use any of the values inherited with parent items and change their values in current entity, whether down the dependency tree, or just the one placed in your map. If you can't do that, and you have to use other intermediary variables, like "set on..", it makes the whole process more complicated and longer. Right now, it's faster just to place a lamp model, a light, and a particle, set their values, and group them in a "staging room" of your map, so you can clone them and ungroup them to tweak the values. It should be the other way around.



#40 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5681 posts

Posted 23 April 2018 - 04:55 PM


Right now, it's faster just to place a lamp model, a light, and a particle, set their values, and group them in a "staging room" of your map, so you can clone them and ungroup them to tweak the values.

Maybe at the beginning, but as said you get used to it. And then there is no real difference in speed. Not to mention that using combined entities reduces the risk of forgetting something when making a copy or using filters.

 


What I found with the second option is even when I set the light_radious manually the entity/engine was ignoring my setting

See my earlier post.


FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#41 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1582 posts

Posted 23 April 2018 - 04:59 PM

Hah, the thing there should be a difference in speed, in favor of the entity class structure :D Have you seen the Actor Class structure in older Unreal engines, Obs? That should give you the idea of what I mean.



#42 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5681 posts

Posted 24 April 2018 - 01:52 AM

Last time I've worked with an UnrealEd was when trying to map for Thief 3, 10 years ago or so. So I can't really remember the details.

 

It is obvious that there is always room for improvement. But it is possible to get to a fast and efficient workflow the way it is now, and that is what I wanted to point out.


FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#43 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1582 posts

Posted 24 April 2018 - 02:45 AM

I havent fired up T3ed for quite some time too, but I rememer how it works (it's common for all Unreal 2.x engines and probably further). The workflow implemented in DR is slower and less clear than that. To make things more streamlined, users should be able to bring the inherited (grayed out) properties/spawnargs to the current level. So the stuff like light radius, color, or texture would initially be grayed out, but if user changes the value, it would be "brought to the current level", not sort of doubled, like it is now (and not working anyway).



#44 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20166 posts

Posted 24 April 2018 - 02:52 AM

Steering the the thread back to my original question, atm I assume there isn't a way to change the origin of the light source when not using def_attach?



#45 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5681 posts

Posted 24 April 2018 - 03:26 PM

@Judith: What do you mean by changing inherited values "is not working anyway"? Of course it does work.

 

@Biker: Using the vertex mode allows you to move the light center around. Alternatively you can use the light_center spawnarg.


FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#46 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1582 posts

Posted 24 April 2018 - 04:12 PM

Obs, see the example I posted above. Try changing a light texture in that wall lamp. The spawnarg gets repeated with new value, it isn't greyed out anymore, but the new light texture doesn't work in game.

 

I also tried to make a few entities of my own, in a way it was done in Unreal actor classes. I.e. I created a light source (inherits light_base), and a lamp model (inherits my light source), and now the light shows up in the editor, along with all its spawnargs, and the radius is visible and editable.

 

Edit: vertex mode allows to move the light center slightly, there seem to be a sort of limit here, not sure about exact values. Still, that's better than immovable light source.


Edited by Judith, 24 April 2018 - 04:55 PM.


#47 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20166 posts

Posted 24 April 2018 - 05:26 PM

@Biker: Using the vertex mode allows you to move the light center around. Alternatively you can use the light_center spawnarg.

Its NOT the light center I have the issue with its "light_origin"



#48 Obsttorte

Obsttorte

    Scripting guru, Mapper

  • Active Developer
  • PipPipPipPipPip
  • 5681 posts

Posted 24 April 2018 - 11:59 PM

Obs, see the example I posted above. Try changing a light texture in that wall lamp. The spawnarg gets repeated with new value, it isn't greyed out anymore, but the new light texture doesn't work in game.

 

I also tried to make a few entities of my own, in a way it was done in Unreal actor classes. I.e. I created a light source (inherits light_base), and a lamp model (inherits my light source), and now the light shows up in the editor, along with all its spawnargs, and the radius is visible and editable.

 

Edit: vertex mode allows to move the light center slightly, there seem to be a sort of limit here, not sure about exact values. Still, that's better than immovable light source.

If you want to change the properties on the attached light, you have to use set ... on. So set texture on flame in your instance. The example you've posted above is a bit confusing, as the entity itself already seems to be a light, so why is there an additional one attached?!

 

Never noticed any limits in regards to moving the light center, though.

 

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


FM's: Builder Roads, Old Habits, Old Habits Rebuild
WIP's: Several. Although after playing Thief 4 I really wanna make a city mission.
Mapping and Scripting: Apples and Peaches
Sculptris Models and Tutorials: Obsttortes Models
My wiki articles: Obstipedia
Let's Map TDM YouTube playlist: ObstlerTube
Texture Blending in DR: DR ASE Blend Exporter

End of shameless self promotion.

#49 Bikerdude

Bikerdude

    Mod hero

  • Member
  • PipPipPipPipPip
  • 20166 posts

Posted 25 April 2018 - 04:16 AM

@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.

 

Capture.JPG Capture1.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, 25 April 2018 - 04:21 AM.


#50 Judith

Judith

    Advanced Member

  • Member
  • PipPipPip
  • 1582 posts

Posted 25 April 2018 - 05:37 AM

 

If you want to change the properties on the attached light, you have to use set ... on. So set texture on flame in your instance. The example you've posted above is a bit confusing, as the entity itself already seems to be a light, so why is there an additional one attached?!

 

Obs, that's a stock TDM light, you can see it under Create entity>Lights>Model lights, Static>Gas. All I did was selecting Show inherited properties check-box in Entity tab, selecting "texture" and changing it from "lights/biground1" to something else. New value for that spawnarg appeared right under it, but it doesn't work in-game. So my guess was either the class system is borked, or something is inherited in a weird or wrong way. As I said before, using stuff like def_attach with invisible light radius and some intermeriary spawnargs is more like temporary workaround, not a real solution.

 

Let me show you how it should probably work, This is UE 2.x actor (entity) class window:

obraz.png

 

The structure is clear and simple, you go to world objects, choose a torch and place it in the map. Then you check the box to show inherited properties, and they appear on a current level (so in the entity placed in map). Then just change the values as you need, so they change from "grayed-out" to "active", and that's it. No doubled values, no intermediary variables.

 

obraz.png

 

There's nothing super-speedy about that workflow, it's just... normal. That's why I highly recommend studying other engines, at least from time to time, to blatantly steal their ideas ;) Not from a coding perspective I guess, but in terms of stuff like structure, UX, and interface design. This is all tried-out and already proven stuff. It saves you time, so you don't have to reinvent the wheel.

 

 

That said, I tried to do something similar to above in DR, and came up with what I expected, the result was similar to Biker's. The light was at the model pivot point, although its properties are editable and the radius is visible, which is good. Using vertex mode or changing the light_center results in an unpredictable effect though, compare the position of the light center in the editor and how it looks in game:

obraz.png

obraz.png


Edited by Judith, 25 April 2018 - 10:29 AM.




Reply to this topic



  


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users